Re: how to implement general macro-insn expansion?

[Greg McGary <greg at mcgary dot org>]

Doug Evans <dje@transmeta.com> writes:

>  > ; If the macro expands to a string, arguments in the input string
>  > ; are refered to with %N.
>  > 
>  > By %N, do you mean that %0, %1, %2 stand for first, second and third
>  > operands in the macro-insn's syntax string?
> 
> Yes.  That was some playing around I did _really_ early on.
> Ignore it unless there's a seed of something useful there.

[ Cc'd to binutils, because of general gas implementation issues. ]

%n is the most convenient form for the assembler macro expander.  For
the CGEN machine description writer, it's not as good as syntax-string
operand names, but no worse than GCC machine descriptions, so it's OK.

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.

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.

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