linux-kernel - Re: PROPOSAL: Extend inline asm syntax with size spec

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]

Message-ID: <20181008061323.GB66819@gmail.com>
Date:   Mon, 8 Oct 2018 08:13:23 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Michael Matz <matz@...e.de>
Cc:     Segher Boessenkool <segher@...nel.crashing.org>,
        Borislav Petkov <bp@...en8.de>, gcc@....gnu.org,
        Richard Biener <rguenther@...e.de>,
        Nadav Amit <namit@...are.com>, Ingo Molnar <mingo@...hat.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Alok Kataria <akataria@...are.com>,
        Christopher Li <sparse@...isli.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H. Peter Anvin" <hpa@...or.com>, Jan Beulich <JBeulich@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Kees Cook <keescook@...omium.org>,
        linux-sparse@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        virtualization@...ts.linux-foundation.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Chris Zankel <chris@...kel.net>,
        Max Filippov <jcmvbkbc@...il.com>,
        linux-xtensa@...ux-xtensa.org
Subject: Re: PROPOSAL: Extend inline asm syntax with size spec


* Michael Matz <matz@...e.de> wrote:

> (without an built-in assembler which hopefully noone proposes).

There are disadvantages (the main one is having to implement it), but a built-in assembler has 
numerous advantages as well:

 - Better optimizations: for example -Os could more accurately estimate true instruction size.

 - Better inlining: as the examples in this thread are showing.

 - Better padding/alignment: right now GCC has no notion about the precise cache layout of the 
   assembly code it generates and the code alignment options it has are crude. It got away with 
   this so far because the x86 rule of thumb is that dense code is usually the right choice.

 - Better compiler performance: it would be faster as well to immediately emit assembly
   instructions, just like GCC's preprocessor library use speeds up compilation *significantly*
   instead of creating a separate preprocessor task.

 - Better future integration of assembly blocks: GCC could begin to actually understand the 
   assembly statements in inline asm and allow more user-friendly extensions to its 
   historically complex and difficult to master inline asm syntax.

I mean, it's a fact that the GNU project has *already* defined their own assembly syntax which 
departs from decades old platform assembly syntax - and how the assembler is called by the 
compiler is basically an implementation detail, not a conceptual choice. The random 
multi-process unidirectional assembler choice of the past should not be treated as orthodoxy.

Thanks,

	Ingo