This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: field-start and varying word sizes



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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]