* Michael Matz <matz at suse.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
