This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: how to implement general macro-insn expansion?
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