variable-length instruction words; bit numbering eureka

[Frank Ch. Eigler]

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
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6u9xoVZbdDOm/ZT0RAj9lAJ0QY6wy2CHzDPauMlB+VRym4tQpUQCdFR5P
Dtj9ly92DgpB92d7rkB+q94=
=3IKV
-----END PGP SIGNATURE-----