multi-insn expansions for macro insns?

multi-insn expansions for macro insns?

[Greg McGary]

define-macro-insn currently allows only a simple 1:1 expansion.

I would like to have it handle 1:n expansions.

E.g., for a MIPS-like CPU which has a `bltz' insn (branch if less than
zero), we would need a two insn sequence to support the more general
2-register `blt' (branch if less than):

blt $s1, $s2, label => sub $at, $s1, $s2
                       bltz $at, label

Is this a desired feature of CGEN?  If so, I'll work on it.

I ask because perhaps CGEN architects consider this (and other
"advanced" features of MIPS assemblers) to overstep the proper role of
an assembler.

If it's a go, how about this as a multi-expansion syntax?:
    (sequence () (emit ...) (emit ...))

Greg

multi-insn expansions for macro insns?

[Doug Evans]

Greg McGary writes:
 > define-macro-insn currently allows only a simple 1:1 expansion.
 > 
 > I would like to have it handle 1:n expansions.
 > 
 > E.g., for a MIPS-like CPU which has a `bltz' insn (branch if less than
 > zero), we would need a two insn sequence to support the more general
 > 2-register `blt' (branch if less than):
 > 
 > blt $s1, $s2, label => sub $at, $s1, $s2
 >                        bltz $at, label
 > 
 > Is this a desired feature of CGEN?  If so, I'll work on it.

It has always been the plan to allow multi-insn expansions of macro-insns.

 > I ask because perhaps CGEN architects consider this (and other
 > "advanced" features of MIPS assemblers) to overstep the proper role of
 > an assembler.

Well, depends on where you draw the line.

IMO there are aspects of the MIPS assembler that don't belong there.
[Maybe Ian can elaborate, I tend to forget the details.]

On the other hand, simple expansions are completely reasonable IMO.
e.g. in sparc there is the `set' pseudo-insn that assigns an immediate
value to a register.  It expands to an appropriate number of
insns to accomplish the job.  I wouldn't have a problem with
supporting that kind of thing in cgen.

 > If it's a go, how about this as a multi-expansion syntax?:
 >     (sequence () (emit ...) (emit ...))

That's the plan.  Note that the intent here is to also allow
specification of runtime determination of what gets emitted.
e.g. (sequence () (if (foo) (emit this) (emit that)))

Re: multi-insn expansions for macro insns?

[Greg McGary]

Doug Evans <dje@transmeta.com> writes:

> On the other hand, simple expansions are completely reasonable IMO.
> ...
>  >     (sequence () (emit ...) (emit ...))
> 
> That's the plan.  Note that the intent here is to also allow
> specification of runtime determination of what gets emitted.
> e.g. (sequence () (if (foo) (emit this) (emit that)))

Cool.  If no one else is actively working on this, I'll proceed.

Re: multi-insn expansions for macro insns?

[Doug Evans]

Greg McGary writes:
 > Doug Evans <dje@transmeta.com> writes:
 > 
 > > On the other hand, simple expansions are completely reasonable IMO.
 > > ...
 > >  >     (sequence () (emit ...) (emit ...))
 > > 
 > > That's the plan.  Note that the intent here is to also allow
 > > specification of runtime determination of what gets emitted.
 > > e.g. (sequence () (if (foo) (emit this) (emit that)))
 > 
 > Cool.  If no one else is actively working on this, I'll proceed.

No one is working on it that I know of.

Thanks!

how to implement general macro-insn expansion?

[Greg McGary]

Doug,

I found this comment in opc-itab.scm before the definition of
`-gen-macro-insn-table':

; The general form is a Scheme expression that is interpreted at runtime to
; decide how to perform the expansion.  Yes, that means having a (perhaps
; minimal) Scheme interpreter in the assembler.

I hope the idea of having a scheme interpreter in the assembler is
outdated.  My plan was to reuse as much of rtl-c.scm as possible to
generate something analogous to sem-switch.c for the gas-runtime
stuff.

; Another thing to do is have a builder for each real insn so instead of
; expanding to text, the macro-expansion could invoke the builder for each
; expanded-to insn.

I don't understand this statement.  Could you elaborate?

Thanks,
Greg

Re: how to implement general macro-insn expansion?

[Greg McGary]

Greg McGary <greg@mcgary.org> writes:

> ; Another thing to do is have a builder for each real insn so instead of
> ; expanding to text, the macro-expansion could invoke the builder for each
> ; expanded-to insn.
> 
> I don't understand this statement.  Could you elaborate?

I stared at the code some more, and I think I understand it better
now.  rtl-c.scm is a toolkit for making builders.  Having a "builder
for each real insn" is what I want to do.

Here's another comment from minsn.scm:

; Expansion:
; 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?

; Multiple insns are separated with '\n'.
; String expansion is a special case of the normal form which is a Scheme
; expression that controls the expansion.

Do you still want to support this?  I'd rather just support the
general scheme expansion.

Greg

Re: how to implement general macro-insn expansion?

[Doug Evans]

Greg McGary writes:
 > I stared at the code some more, and I think I understand it better
 > now.  rtl-c.scm is a toolkit for making builders.  Having a "builder
 > for each real insn" is what I want to do.

I _think_ that's the way to go.
As you get into it feel free to change your mind. :-)

 > Here's another comment from minsn.scm:
 > 
 > ; Expansion:
 > ; 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.

 > ; Multiple insns are separated with '\n'.
 > ; String expansion is a special case of the normal form which is a Scheme
 > ; expression that controls the expansion.
 > 
 > Do you still want to support this?  I'd rather just support the
 > general scheme expansion.

Dunno.  Feel free to ignore it for now.

Re: how to implement general macro-insn expansion?

[Greg McGary]

Doug Evans <dje@transmeta.com> 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

Re: how to implement general macro-insn expansion?

[Doug Evans]

Greg McGary writes:
 > 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.

Some notes:

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.

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.

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

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

Re: how to implement general macro-insn expansion?

[Greg McGary]

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

Re: how to implement general macro-insn expansion?

[Doug Evans]

Greg McGary 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?

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.

Re: how to implement general macro-insn expansion?

[Greg McGary]

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