variable-length instruction words; bit numbering eureka

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

There has been a long-standing problem in using cgen for
variable-length instruction words, for instruction sets with the
"lsb0?" flag set to "#t".  I think now that this is pilot
error.  Look at types.scm, especially the comments surrounding
<bitrange>.  It is clear that what is intended is that the N-bit
base part of the instruction word be numbered N-1..0 (or 0..N-1 if lsb0?=#f),
even if more bits follow the instruction.  For example, if
base-insn-bitsize=16 and lsb0?=#t, then a hypothetical 48-bit
instruction would have its bits numbered thusly:

; Examples:
;
; lsb0? = #f
; insn-word-length = 2, 4
; endian = little
; | 8 ... 15 | 0 ... 7 | 40 ... 47 | 32 ... 39 | 24 ... 31 | 16 ... 23 |
;
; lsb0? = #t
; insn-word-length = 2, 4
; endian = little
; | 7 ... 0 | 15 ... 8 | 23 ... 16 | 31 ... 24 | 39 ... 32 | 47 ... 40 |
;
; lsb0? = #f
; insn-word-length = 2, 4
; endian = big
; | 0 ... 7 | 8 ... 15 | 16 ... 23 | 24 ... 31 | 32 ... 39 | 40 ... 47 |
;
; lsb0? = #t
; insn-word-length = 2, 4
; endian = big
; | 15 ... 8 | 7 ... 0 | 47 ... 40 | 39 ... 32 | 31 ... 24 | 23 ... 16 |


This makes way more sense than starting numbering at the left from 47,
based on the longest possible instruction.


- FChE

PGP signature