CGEN: Macro insns

CGEN: Macro insns

[Dave Brolley]

Hi,

I have a scenario in which I have a short form of an insns which I would 
like to implement using a macro insn. The situationj is similar to the 
following:

There exists an insn which has two operands:

insn    reg1,reg2

If reg2 is not specified, it is assumed to be the same register as reg 
1. So, I implement the insn as

(dni insn "an instruction" ()
   "insn $dest-reg,$src-reg"
   (+ OP_INSN dest-reg src-reg)
   (nop)
)

and I tried to implemented the short form as

(dnmi insn-short "short form of insn" ()
   "insn $dest-reg"
   (emit insn dest-reg (src-reg dest-reg))
)

Unfortunately, when using the short form, the field associated with the 
src-reg operand is assigned the value zero rather than the value of the 
field associated with dest-reg, as I had expected. Is this supposed to 
work? Any other suggestions?

Thanks,
Dave

Re: CGEN: Macro insns

[Ben Elliston]

>>>>> "Dave" == Dave Brolley <brolley@redhat.com> writes:

  Dave> (dnmi insn-short "short form of insn" ()
  Dave>    "insn $dest-reg"
  Dave>    (emit insn dest-reg (src-reg dest-reg))
  Dave> )

  Dave> Unfortunately, when using the short form, the field associated with the 
  Dave> src-reg operand is assigned the value zero rather than the value of the 
  Dave> field associated with dest-reg, as I had expected. Is this supposed to 
  Dave> work? Any other suggestions?

If don't believe it has been done before, but it should work.  Would
you like to try fixing it?  Also, have you tried:

	 (emit insn dest-reg dest-reg)?

Ben

Re: CGEN: Macro insns

[Dave Brolley]

Ben Elliston wrote:

>>>>>> "Dave" == Dave Brolley <brolley@redhat.com> writes:
>>>>> 
> 
>   Dave> (dnmi insn-short "short form of insn" ()
>   Dave>    "insn $dest-reg"
>   Dave>    (emit insn dest-reg (src-reg dest-reg))
>   Dave> )
> 
>   Dave> Unfortunately, when using the short form, the field associated with the 
>   Dave> src-reg operand is assigned the value zero rather than the value of the 
>   Dave> field associated with dest-reg, as I had expected. Is this supposed to 
>   Dave> work? Any other suggestions?
> 
> If don't believe it has been done before, but it should work.  Would
> you like to try fixing it?  Also, have you tried:
> 
> 	 (emit insn dest-reg dest-reg)?

Just tried this. CGEN barfs. I should probably work on finishing the 
rest of this port before taking time to see if I can fix this. In the 
mean time, if anyone has the time......

Dave

Re: CGEN: Macro insns

[Greg McGary]

Dave Brolley <brolley@redhat.com> writes:

> I have a scenario in which I have a short form of an insns which I would 
> like to implement using a macro insn. The situationj is similar to the 
> following:
> 
> There exists an insn which has two operands:
> 
> insn    reg1,reg2
> 
> If reg2 is not specified, it is assumed to be the same register as reg 
> 1. So, I implement the insn as
> 
> (dni insn "an instruction" ()
>    "insn $dest-reg,$src-reg"
>    (+ OP_INSN dest-reg src-reg)
>    (nop)
> )
> 
> and I tried to implemented the short form as
> 
> (dnmi insn-short "short form of insn" ()
>    "insn $dest-reg"
>    (emit insn dest-reg (src-reg dest-reg))
> )
> 
> Unfortunately, when using the short form, the field associated with the 
> src-reg operand is assigned the value zero rather than the value of the 
> field associated with dest-reg, as I had expected. Is this supposed to 
> work? Any other suggestions?

Months ago, I observed that macro-insns as currently implemented have
very limited usefulness.  The args to `emit' are error-checked, but
otherwise completely ignored.  The only thing you can do with a macro
insn is omit some operands and have them be filled with zero, or
change the order of operands in the syntax string.

I order to define short versions collapsed src & dest regs, I needed
to define a multi-field with an inserter that dup'ed the reg#, and
an extractor that ignored one sub-field.

Here's an example for a MIPS-like 32-bit generic RISC:

(dnf f-src1     "source register 1"          () 25  5)
(dnf f-src2     "source register 2"          () 20  5)
(dnf f-dest     "destination register"       () 15  5)
(df  f-simm11   "signed 11-bit immediate"    () 10 11  INT #f #f)

(dnmf f-src1dest "dest dup'ed into src1"     () UINT
     (f-src1 f-dest)
     (sequence ()
	       (set (ifield f-src1) (and (ifield f-src1dest) (const #x1f)))
	       (set (ifield f-dest) (and (ifield f-src1dest) (const #x1f))))
     (sequence () (set (ifield f-src1dest) (ifield f-dest))))

(dnop src1      "source register 1"          () h-gr    f-src1)
(dnop src2      "source register 2"          () h-gr    f-src2)
(dnop dest      "destination register"       () h-gr    f-dest)
(dnop simm16    "signed 16-bit immediate"    () h-sint  f-simm16)
(dnop src1dest  "dest dup'ed onto src1"      () h-gr    f-src1dest)

(dni sub3r "Subtract Register" ()
     "sub $dest,$src1,$src2"
     (+ OP_SUBr src1 src2 dest (f-simm11 0))
     (set dest (sub src1 src2))
     ())

(dni sub2r "Subtract Register Two-Operand" (NO-DIS ALIAS)
     "sub $src1dest,$src2"
     (+ OP_SUBr src1 src2 dest (f-simm11 0))
     (set src1dest (sub src1dest src2))
     ())

Greg

Re: CGEN: Macro insns

[Dave Brolley]

Greg McGary wrote:

> 
> Months ago, I observed that macro-insns as currently implemented have
> very limited usefulness.  The args to `emit' are error-checked, but
> otherwise completely ignored.  The only thing you can do with a macro
> insn is omit some operands and have them be filled with zero, or
> change the order of operands in the syntax string.
> 
> I order to define short versions collapsed src & dest regs, I needed
> to define a multi-field with an inserter that dup'ed the reg#, and
> an extractor that ignored one sub-field.

Uggggghhh.....I'll keep this in mind should I not find time to fix the 
real problem. What is the ALIAS attribute? Does it keep the decode from 
complaining about the ambiguity?

Dave

Re: CGEN: Macro insns

[Greg McGary]

Dave Brolley <brolley@redhat.com> writes:

> What is the ALIAS attribute? Does it keep the decode from 
> complaining about the ambiguity?

Yes.