Re: how to implement general macro-insn expansion?

[Doug Evans <dje at transmeta dot com>]

Greg McGary writes:
 > I had originally stated that I wanted to first implement the most
 > general scheme form of expansion (sequence () ...).  Since then, I
 > have changed my mind, since none of the multi-insn macro expansions
 > need runtime evaluation, and string substitution suits me just fine.
 > Now, I'm faced with gas's inadequacy to handle general multi-insn
 > macro expansion at the machine-dependent layer.

Some notes:

1) I was kind of thinking the macro-insn expander would call
   appropriate insn emitters rather than doing string substitution.
   That doesn't preclude going the latter route though.

One goal of cgen is to have a large part of the assembler in
a library, gas then becoming just one user of the library.
Whether macro-insns should be part of this library I dunno.
At the very least, don't tie the specification of macro-insns
to any gas implementation artifacts.

 > read_a_source_file() is the outer machine-independent loop that
 > handles all assembler directives (a.k.a. pseudo-ops) and only invokes
 > the machine-dependent md_assemble() when it has a line that looks like
 > an instruction.  md_assemble() operates on a single line only.
 > read_a_source_file() can handle gasp macro expansion, but that doesn't
 > fit with the macro-insn model.  The strength of macro-insns is that a
 > single opcode can be overloaded to handle multiple insns (both real
 > insns and 1:n macros) differentiated by operand formats and actual
 > operand values (e.g., MIPS).  We can't know until we're inside
 > md_assemble and subsidiaries if we have a macro insn, but it's outside
 > md_assemble that we want to push the old input source's context take
 > input from the new input source which is the macro's expansion string.

2) Is this something that has to be handled at a layer above md_assemble?
   For example, I'm not sure I want to support the result of the expansion
   containing pseudo-ops.
   One can implement this macro-processing in a reasonable way without
   returning from md_assemble (assuming the result of the
   macro-expansion only contains things that md_assemble should
   otherwise handle).

 > I see no way around the need to change the md_assemble() interface.
 > Somehow md_assemble() needs to return a `sb' (string block)
 > representing the expansion of a macro-insn so that read_a_source_file()
 > can push it as a nested input source and continue assembling.  A
 > sneaky way to do this that doesn't require changing any of the
 > zillions of instances of md_assemble is to pass a zeroed sb as a
 > second argument, then detect macro-insn by whether or not the sb's
 > fields come back filled-in.  However, I don't like sneakiness and gas
 > is sourceware, so I'm content to hack all instances of md_assmeble to
 > take the second argument and return a boolean to indicate what we did.
 > md_assmble() should return nonzero if it assembled an insn, and should
 > return 0 if a macro expansion was deposited into `sb'.
 > 
 > Sound reasonable?
 > 
 > Greg