From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg McGary To: Doug Evans Cc: cgen@sourceware.cygnus.com, binutils@sourceware.cygnus.com Subject: Re: how to implement general macro-insn expansion? Date: Tue, 26 Dec 2000 17:43:00 -0000 Message-id: References: <200012182002.NAA03245@kayak.mcgary.org> <14910.31997.701815.400981@casey.transmeta.com> <14912.53918.827200.424561@casey.transmeta.com> X-SW-Source: 2000-q4/msg00292.html Doug Evans 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