Re: supporting mixed 16/32-bit ISA's

Re: supporting mixed 16/32-bit ISA's

[Peter.Targett]

> > 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.
>
> I'm not sure what you mean by "half-word endianized".  Please clarify.

So the following pretend 32-bit instruction opcode "0x12345678" is stored:

     little-endian -> 34127856
     big-endian    -> 12345678

> I did a 16/32 port last year, though unfortunately it's proprietary,
> so it's not in the public repo.

Thanks for the snippets - I will investigate these.

Peter.

Re: supporting mixed 16/32-bit ISA's

[Greg McGary]

Peter.Targett@arccores.com writes:

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

I'm not sure what you mean by "half-word endianized".  Please clarify.

I did a 16/32 port last year, though unfortunately it's proprietary,
so it's not in the public repo.

The CPU is spec'ed with big-endian bytes, but little-endian bits (lsb
is bit 0).  However, I wrote the CGEN port with bit-endian bits (msb
is bit 0).  This worked out best since it means the base insn always
occupies bit positions 0..15 (with lsb=0, 16-bit insns would have
the base insn at bits 0..15, but for 32-bit insns, the base insn
would be at bits 16..31)

I can give you some sanitized snippets to show how the port was setup:

;;; Architecture.

(define-arch
  (name xxx)
  (default-alignment unaligned)
  (insn-lsb0? #f)
  (machs yyy)
  (isas xxx))

;;; Instruction set parameters.

(define-isa
  (name xxx)
  (default-insn-bitsize 32)
  (base-insn-bitsize 32)
  (default-insn-word-bitsize 16)
  (liw-insns 1)
  (parallel-insns 1))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Instruction fields.

(dnf f-op6      "6-bit opcode"                  ()  0  6)
(dnf f-dst      "destination register"          ()  6  5)
(dnf f-src      "source register"               () 11  5)
(dnf f-uimm16   "16-bit unsigned immediate"     () 16 16)

(define-ifield (name f-uimm5)
  (comment "5-bit immediate")
  (start 11) (length 5) (mode UINT)
  (encode (value pc) (if SI (eq SI value -1) (const SI 0) value))
  (decode (value pc) (if SI (eq SI value 0) (const SI -1) value))
  (minval 0) (maxval 29))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Instruction Operands.

(define-operand (name uimm5)
  (comment "5-bit immediate, unsigned with special encoding")
  (type h-uimm5)
  (index f-uimm5)
  (handlers (parse "uimm5")))

(define-operand (name uimm16hi)
  (comment "high order 16-bit immediate, unsigned")
  (type h-uimm16)
  (index f-uimm16)
  (handlers (parse "uimm16") (print "uimm16hi")))

(define-operand (name uimm16lo)
  (comment "low order 16-bit immediate, unsigned")
  (type h-uimm16)
  (index f-uimm16)
  (handlers (parse "uimm16")))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Instruction definitions.

(define-pmacro (alu-insn mnemonic comment)
  (begin
    (dni (.sym mnemonic "2i16lo") (.str comment " / 16-bit Immediate Low") ()
         (.str mnemonic " $dst,$uimm16lo")
         (+ (.sym "OP6_" (.upcase mnemonic) "I") dst (f-uimm5 30) uimm16lo)
         (nop) ())
    (dni (.sym mnemonic "2i16hi") (.str comment " / 16-bit Immediate High") ()
         (.str mnemonic " $dst,$uimm16hi")
         (+ (.sym "OP6_" (.upcase mnemonic) "I") dst (f-uimm5 31) uimm16hi)
         (nop) ())
    (dni (.sym mnemonic "2i5") (.str comment " / 5-bit Immediate") ()
         (.str mnemonic " $dst,$uimm5")
         (+ (.sym "OP6_" (.upcase mnemonic) "I") dst uimm5)
         (nop) ())))

The field f-uimm5 is restricted to the range 0..29 because 30 and 31
are reserved to designate that a 16-bit immediate follows the base
insn.  (30 means the immediate is the low 16 bits of a 32-bit word,
and 31 means it is the high 16 bits)

I need special parse handlers for immediates in order to handle %l()
and %h() modifers that pick off the low and high halves of words, and
to range check the restricted 5-bit values.  I need special print
handler for uimm16hi in order to shift the value left before printing.

As for why I have these particular values in the define-isa:
  (default-insn-bitsize 32)
  (base-insn-bitsize 32)
  (default-insn-word-bitsize 16)
I don't remember exactly, but that's what worked!  8^)

That should be enough to get you started.

Greg

supporting mixed 16/32-bit ISA's

[Peter.Targett]

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.