From mboxrd@z Thu Jan  1 00:00:00 1970
From: Greg McGary <greg@mcgary.org>
To: Doug Evans <dje@transmeta.com>
Cc: cgen@sourceware.cygnus.com, binutils@sourceware.cygnus.com
Subject: Re: how to implement general macro-insn expansion?
Date: Tue, 09 Jan 2001 15:23:00 -0000
Message-id: <msitnoz4w8.fsf@mcgary.org>
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> <14922.17101.201404.651828@casey.transmeta.com> <ms4rzp1vao.fsf@mcgary.org> <14922.27451.204955.19357@casey.transmeta.com>
X-SW-Source: 2001-q1/msg00049.html

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