Re: ALIAS instructions are messed up?

Re: ALIAS instructions are messed up?

[Joern Rennecke]

> Whether to disallow alias insns entirely is a separate question. Dunno.
> [We could still keep it for macro-insns.
> And I realize there are a few ports that currently use it, or at  
> least specify > it.]

Currently, macro-instructions can't be used in all instances where
it should be natural to use them.
When you want to set a multi-ifield to a constant, you end up with
the entire costant being added in in the bit position of each of
constituent simple bitfields.

By adding an ALIAS instruction by hand, you can at least work around
the problem by setting only simple bitfields to constants.

Re: ALIAS instructions are messed up?

[Doug Evans]

Joern Rennecke wrote:
>> Whether to disallow alias insns entirely is a separate question. Dunno.
>> [We could still keep it for macro-insns.
>> And I realize there are a few ports that currently use it, or at 
>> least specify > it.]
>
> Currently, macro-instructions can't be used in all instances where
> it should be natural to use them.
> When you want to set a multi-ifield to a constant, you end up with
> the entire costant being added in in the bit position of each of
> constituent simple bitfields.

Let's fix this.  Do you have an example readily available?

>
> By adding an ALIAS instruction by hand, you can at least work around
> the problem by setting only simple bitfields to constants.

Good point.

Re: ALIAS instructions are messed up?

[Joern Rennecke]

Quoting Doug Evans <dje@sebabeach.org>:
> Let's fix this.  Do you have an example readily available?

The port where I have most recently encountered this is under NDA,
so I just made up a relevant macro insn for the frv:

Index: frv.cpu
===================================================================
RCS file: /cvs/src/src/cpu/frv.cpu,v
retrieving revision 1.25
diff -u -r1.25 frv.cpu
--- frv.cpu     7 Jan 2009 01:09:24 -0000       1.25
+++ frv.cpu     5 Oct 2009 21:36:15 -0000
@@ -5786,6 +5786,12 @@
  (register-transfer-spr movgs OP_03 OPE1_06 GRj spr u-gr2spr  
"transfer gr->spr")
  (register-transfer-spr movsg OP_03 OPE1_07 spr GRj u-spr2gr  
"transfer spr->gr")

+(dnmi movgs_pcsr ""
+       ()
+       ("movgs_pcsr$pack $GRj")
+       (emit movgs pack GRj (spr 1))
+)
+
  ; Integer Branch Conditions
  (define-pmacro (Inev cc) (const BI 0))
  (define-pmacro (Ira  cc) (const BI 1))
[bld-frv]$ cat tst.S
movgs sp,pcsr
movgs sp,hsr49
movgs_pcsr sp
[bld-frv]$ gas/as-new -ahld tst.S
FRV GAS  tst.S                  page 1


    1 0000 800C1181      movgs sp,pcsr
    2 0004 820C1181      movgs sp,hsr49
    3 0008 820C1181      movgs_pcsr sp

ALIAS instructions are messed up?

[Doug Evans]

Blech.  Handling of ALIAS instructions is messed up.

 From insn.scm:-insn-parse:

        (let ((ifield-assertion (if (not (null? ifield-assertion))
                                    ifield-assertion
                                    #f))
              (semantics (if (not (null? semantics))
                             semantics
                             #f))
              (format (-parse-insn-format (string-append errtxt " format")
                                          fmt))
              (comment (parse-comment comment errtxt))
              ; If there are no semantics, mark this as an alias.
              ; ??? Not sure this makes sense for multi-insns.
              (atlist-obj (if semantics
                              atlist-obj
                              (atlist-cons (bool-attr-make 'ALIAS #t)
                                           atlist-obj)))
              (syntax (parse-syntax syntax errtxt))
              (timing (parse-insn-timing errtxt timing))
              )

If this were a `let*', then things would be a bit clearer, but not 
completely.
[the checking for alias insns won't work if it's expecting the previous 
assignment of semantics to change () to #f]

This comes up because generating the html doc for xc16x.cpu crashes 
because its "nop" instruction has () for semantics.

I can't remember if there's any usefulness to ALIAS insns that isn't 
provided by macro-insns.
Can anyone?

I don't have too strong a preference on what to do here (though I 
reserve the right to change my mind :-)).
Since, e.g., simulators rightly ignore ALIAS insns it seems like we want 
to flag insns in .cpu files with missing/empty semantics as an error and 
not silently convert them to aliases.
Nop insns would be required to specify (nop) for their semantics.
It'd be interesting to see if making this change causes any changes to 
the generated code.

Whether to disallow alias insns entirely is a separate question.  Dunno.
[We could still keep it for macro-insns.
And I realize there are a few ports that currently use it, or at least 
specify it.]