From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: dje@transmeta.com (Doug Evans) Cc: cgen@sources.redhat.com Subject: Re: field-start and varying word sizes Date: Tue, 03 Jul 2001 15:32:00 -0000 Message-id: References: <200107032054.NAA01495@geoffk.org> <15170.15391.989073.581389.cygnus.local.cgen@casey.transmeta.com> X-SW-Source: 2001-q3/msg00005.html 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