This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: how to implement general macro-insn expansion?


Doug Evans <dje@transmeta.com> writes:

>  > 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?
> 
> Dunno.  Are we talking gas implementation or cgen design?

Mostly gas.

> If all of this is just how you're going to implement something
> in gas I don't care (much).  But I'd like to see how this will appear in cgen.

I have been considering wrapping CGEN_OPCODE.format in a union, and
adding (const char *) as an alternative.  Like so:

  union {
    /* Format entry for hard insn.  */
    const CGEN_IFMT *format;
#define CGEN_OPCODE_FORMAT(opc) ((opc)->u.format)
#define CGEN_OPCODE_MASK_BITSIZE(opc) CGEN_IFMT_MASK_LENGTH (CGEN_OPCODE_FORMAT (opc))
#define CGEN_OPCODE_BITSIZE(opc) CGEN_IFMT_LENGTH (CGEN_OPCODE_FORMAT (opc))
#define CGEN_OPCODE_IFLDS(opc) CGEN_IFMT_IFLDS (CGEN_OPCODE_FORMAT (opc))
    /* string macro insn.  */
    const char *expansion;
#define CGEN_OPCODE_MACRO_EXPANSION(opc) ((opc)->u.expansion)
  } u;

Based on attributes, we'll either insert strings in the u.expansion
template and return that from md_assmeble, or we'll do the usual
thing.  When the general builder-function multi-insn expansions are
implemented, a third alternative would be added which is a
specification of the builder to use (either a code or a function pointer).

That brings me to the matter of macro-insn attributes.  At present,
there's only one: ALIAS.  Unfortunately, it has been over-used to mean
two things:

	1) ignore for sim
	2) 1:1 alias for a real insn

IMO, ALIAS should only mean (2).  We need attributes sufficient to
express the following:

	1) ignore for sim
	2) 1:1 alias for a real insn (the expansion is degenerate)
	3) expansion is a string template that wants textual
	   substitution of operand strings at assembly time.
	4) expansion is a builder function that wants to be called
	   at assembly time, passing operand values.

We could do it with three attrs:

	Primary attribute for all macros is MACRO, which always
	means ignore for sim.  Secondary attrs tell how to expand
	the macro.

	ALIAS	  = 1:1 alias for real insn (degenerate expansion)
	STRING	  = expansion is a string template
	<default> = expansion is a builder function

	<default> means no secondary attribute.  This is done to
	conserve attribute bits.  If one wanted to burn attr bits,
	we could add a BUILDER attribute.

Comments?

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]