Re: how to implement general macro-insn expansion?

[Greg McGary <greg at mcgary dot org>]

Doug Evans <dje@transmeta.com> writes:

> 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.

Earlier, I had stated a preference for emitters as well, but then I
was seduced by the convenience of writing simple string expansions.

> 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.

OK.  In that case, md_assemble shouldn't deal with the `sb', but
should rather return a simple char* expansion, if the insn was a
macro.  The caller can then wrap the string in an `sb', as necessary.

> 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.

The main thing I wanted at the layer above md_assemble() was the ability
to define numbered local labels.  I have no immediate plans to use
pseudo-ops, but I didn't want to close the door on them either.

>    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 was striving to reuse existing mechanisms, make local labels and
pseudo-ops easily usable, which is best achievable by having
md_assemble() return an expansion.  Can you live with that?

Greg