RE: Generating assembly code without macro-instructions

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes:

 Dave> On 27 February 2006 14:48, Nikolaos Kavvadias wrote:
 >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
 >> 
 >> Hi there
 >> 
 >> i have a question. Is there any way for mature ports (e.g. MIPS,
 >> Alpha, SPARC) to generate directly "real" assembly instructions
 >> (as these are shown by "gas -l") instead of macro-instructions?
 >> See below for such a case.

 Dave> Well, yes, it /could/ be done.  It would be pretty trivial
 Dave> really; you'd just need to go through the insn patterns in the
 Dave> .md file, find the ones that have output templates that mention
 Dave> any of the macros, and replace them with templates that
 Dave> generate the expanded version directly.  You might also need to
 Dave> check the md .c and .h files as well, because they often
 Dave> contain assembler fragments, but they would be just as easy to
 Dave> convert.

 Dave> Then again, it would make all the output source files larger,
 Dave> and you'd lose the data-hiding/abstraction advantages of having
 Dave> macros.

We're talking about GCC code generation here, I assume...

Doesn't the latest GCC avoid macros?  I thought it did, and that is
good.

Those MIPS built-in macros always were a bad idea in my view, but then
maybe I'm a traditionalist.  In any case, there are lots of good
reasons for the compiler to avoid them.

One is that the code generator has to know about branch delay slots,
and it can't do that sanely with macros.  (Oh yes, you can have the
assembler rearrange your code to move instructions into delay slots
behind your back.  Barf.)

The more compelling argument is scheduling.  The assembler is clueless
about scheduling, fortunately.  But the compiler is not.  If the
compiler's code generator always generates real machine instructions,
it can schedule them better than what you would get if the assembler
just blindly expands macros.

The "li" example may not show that so clearly, because in the machine
I know best at least, its two component instructions can be adjacent
without penalty.  However, that isn't true in other cases, such as
unaligned loads.  "ulw" is NOT the right way to load an unaligned int;
the right way is to generate the two parts ("lwl" and "lwr") and
schedule them separately.

	 paul