This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Generating assembly code without macro-instructions


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. 

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

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

> BTW can this be done for "dot" instructions (assembly
> directives) too, are these are required information for the linker?

  Don't know what you mean here.  Since directives don't represent assembly
instructions but instead are commands to the assembler itself, the idea of gcc
generating the 'real' forms doesn't make sense.  What would be the 'real' form
of a .title directive, for instance?  Or a .org directive, for that matter?
Some of them pass on information to the linker, some of them don't.
 
> An example of a macro-instruction that could be replaced on-the-fly by
> two "real" assembly instructions for the MIPS:
> 
> Macro:
> li %reg, %imm
> 
> Actual assembly:
> lui %0, \%hi(%1)
> ori %0, %0, %1
            ^^^^^ 
  (Irrelevant aside: Don't you want a %lo on that %1?)

  This example illustrates the question about /why/ you'd want to undertake
this.  Gcc just wants to load a 32-bit value into a 32-bit register.  Gcc
doesn't care about how many n-bit parts it has to be broken up into, or which
order they are combined, or whether they are combined using signed or unsigned
arithmetic on the parts.  Gcc just wants %reg to contain %imm.  Placing the
low-level knowledge about how to do this into the assembler is a better place
to put it than in the compiler, because it's nicely decoupled in that way
(remember that people write hand-coded assembly as well as feeding compiler
output to assemblers, and those people want to use macros like 'li' because it
protects them against typos in what would otherwise be a very over-repeated
instruction sequence); the method of doing the combination - which relates to
the reloc types available in the linker, but not to anything going on in the
compiler - shouldn't matter to gcc, and with this macro it doesn't need to
know anything about it.

  If gcc was to generate the expanded form itself, and whoever defines the ABI
wanted to re-organize the usage and semantics of HI16/LO16 relocs, they'd have
to get gcc to change in sync with the changes to the lower end of the
toolchain; it's less difficult to maintain when changes are insulated from
each other by wrapping them up in macros.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]