This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: how to implement general macro-insn expansion?
- To: Greg McGary <greg at mcgary dot org>
- Subject: Re: how to implement general macro-insn expansion?
- From: Doug Evans <dje at transmeta dot com>
- Date: Wed, 27 Dec 2000 11:28:13 -0800 (PST)
- Cc: cgen at sourceware dot cygnus dot com, binutils at sourceware dot cygnus dot com
- References: <200012182002.NAA03245@kayak.mcgary.org><14910.31997.701815.400981@casey.transmeta.com><ms1yv37fcw.fsf_-_@mcgary.org><msy9xb5vhp.fsf@mcgary.org><14912.53918.827200.424561@casey.transmeta.com><mselyu1vw3.fsf@mcgary.org>
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