linux-kernel - Re: [PATCH] doc: code generation style

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 5 Mar 2020 11:21:23 -0800
From:   Matthew Wilcox <willy@...radead.org>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     torvalds@...ux-foundation.org, corbet@....net,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel,
        linux-doc@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] doc: code generation style

On Thu, Mar 05, 2020 at 10:02:53PM +0300, Alexey Dobriyan wrote:
> I wonder if it would be useful to have something like this in tree.
> 
> It states trivial things for anyone who looked at disassembly few times
> but still...

It's a bit x86-specific, and it ignores things which matter more like
paying attention to cacheline boundaries in structures.  I'm also not
convinced that those who come after us in ten years and have to widen
everything from int to long will thank us for saving a few bytes of
Icache.

> +.. code-block:: c
> +
> +        int g(int, int, flag_t);
> +        int f(int a, int b)
> +        {
> +                return g(a, b, FLAG_C);
> +        }
> +
> +Appending an argument at the end adds minimum amount of code:
> +
> +.. code-block:: none
> +
> +        f:
> +                mov     edx, FLAG_C
> +                jmp     g
> +
> +Appending an argument in the middle or in the beginning will generate
> +reshuffle sequence:
> +
> +.. code-block:: none
> +
> +        f:
> +                mov     edx, esi
> +                mov     esi, edi
> +                mov     edi, FLAG_C
> +                jmp     g

But if f is static inline, then it makes no difference at all.

> +Constants which don't fit into 12-bit window on arm will be loaded from memory
> +or constructed with 2 loads:

The 12-bit window on ARM is 8 bits rotated by a power of 4.  So for example,
0xc000003f is a valid constant, but 0x000001f7 is not.  I don't know what
arm64 does for constants.