This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: field-start and varying word sizes
- To: dje at transmeta dot com (Doug Evans)
- Subject: Re: field-start and varying word sizes
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: 03 Jul 2001 15:47:42 -0700
- CC: cgen at sources dot redhat dot com
- References: <200107032054.NAA01495@geoffk.org> <15170.15391.989073.581389.cygnus.local.cgen@casey.transmeta.com>
dje@transmeta.com (Doug Evans) writes:
> Geoff Keating writes:
> > Despite the comment, m32r has
> > (insn-lsb0? #f)
> > and so all this code comes down to the trivial case anyway.
>
> The comment was directed towards the kind of chip the m32r is.
> You're taking the comment too literally.
>
> > OK to commit?
>
> I'm not convinced. [not saying I can't be, just that I'm not there yet]
>
> What should be returned in the following case? [for example]
>
> lsb0? #f
> wanted-word-len 32
> recorded-word-len 16
> endian little
An interesting question. The current code, and the code with my patch,
both return
(bitrange-start bitrange)
but in this case, I believe that the correct thing is to return
(+ (bitrange-start bitrange) (- wanted-word-len
recorded-word-len))
and so this code doesn't currently work for this case, and still
doesn't work with my patch.
An interesting question is whether this can ever happen. It would
imply that you have a port with little-endian instructions, and
variable-length instructions, but you're numbering your bits starting
from the end of the instruction; so you might have
(dnf f-f1 "some byte" () 0 8)
which refers to byte 1 for 16-bit-long instructions, but to
byte 3 for for 32-bit-long instructions.
Now, it's not that this doesn't make sense; you would have
(dnf f-op1-16 "first byte for short insns" () 8 8)
(dnf f-op1-32 "first byte for long insns" () 24 8)
(dnf f-op2-32 "middle word for long insns" () 8 16)
and then perhaps
(dni short
"A short instruction"
()
("short")
(+ (f-op1-16 #x01) (f-f1 #x00))
()
()
)
(dni long
"A longer instruction"
()
("long")
(+ (f-op1-32 #x02) (f-op2-32 #x1234) (f-f1 #x56))
()
()
)
and these would describe the instructions with bytes
01 00
and
02 34 12 56
respectively. I don't think it would be a good idea to write a .cpu
file like this, though.
--
- Geoffrey Keating <geoffk@geoffk.org>