supporting mixed 16/32-bit ISA's

[Peter.Targett@arccores.com]

I've had a look through the CGEN mail archive and came across the mail
below.

I'm particularly interested in CGEN's ability to describe mixed 16/32
bit ISA's. We have a new ISA at ARC which has a truely intermixed
16/32 instruction set - basically, can I describe the ISA in CGEN? The
32-bit instructions (and long immediates that can form part of an
instruction) are actually stored half-word endianized. Would this also
be a problem?

Thanks in advance for any advise,

Peter.
--
peter.targett@arccores.com

---------------------------------------------------------------------
Broken decoder for 16/32 ISAs
     To: cgen at sources dot redhat dot com
     Subject: Broken decoder for 16/32 ISAs
     From: Ben Elliston <bje at redhat dot com>
     Date: Thu, 31 May 2001 23:08:27 +1000 (EST)

I have been debugging a problem in the generated decoder for the
simulators.  Here is the scenario, involving an ISA with a mix of 16
and 32 bit instructions (and lsb0? set to #f, so most significant bit
is bit 0).

The 16 bit instructions are laid out like so:

                +---------+---------+
                | insn16  |         |
                +---------+---------+
                0        15

And the 32 bit instructions are laid out like so:

                +-------------------+
                |      insn32       |
                +-------------------+
                0                  31

The (-gen-decode-bits) function computes, amonst other things, the
amount to shift a sequence of bits to the right, whereby they are then
masked and examined by the decoder.

For the architecture I've briefly described above, I believe the logic
in utils-sim.scm is wrong:

  (shift (- (if lsb0?
                     (- first bits -1)
                     (- (+ start size) (+ first bit))    <----
               pos)))

The line indicated is used to compute the shift value when lsb0? is
#f.  Even for 16 bit instructions, the shift value needs to be at
least 16 to get at the bits of insn16 (see above).

The `size' variable seems to be passed in by callers, but it's unclear
how this value is calculated or what it is meant to be in a variable
length ISA.  Shouldn't size really be the sizeof(insn) here?  I'm a
bit out of my depth in this part of cgen, but any suggestions would be
much appreciated.