* supporting mixed 16/32-bit ISA's
@ 2002-01-22 3:57 Peter.Targett
2002-01-22 8:27 ` Greg McGary
0 siblings, 1 reply; 3+ messages in thread
From: Peter.Targett @ 2002-01-22 3:57 UTC (permalink / raw)
To: cgen
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: supporting mixed 16/32-bit ISA's
2002-01-22 3:57 supporting mixed 16/32-bit ISA's Peter.Targett
@ 2002-01-22 8:27 ` Greg McGary
0 siblings, 0 replies; 3+ messages in thread
From: Greg McGary @ 2002-01-22 8:27 UTC (permalink / raw)
To: Peter.Targett; +Cc: cgen
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: supporting mixed 16/32-bit ISA's
@ 2002-01-22 8:56 Peter.Targett
0 siblings, 0 replies; 3+ messages in thread
From: Peter.Targett @ 2002-01-22 8:56 UTC (permalink / raw)
To: cgen
> > 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-01-22 16:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-22 3:57 supporting mixed 16/32-bit ISA's Peter.Targett
2002-01-22 8:27 ` Greg McGary
2002-01-22 8:56 Peter.Targett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).