Re: btw, cgen fix in progress

Re: btw, cgen fix in progress

[Geoff Keating]

[I'm moving this back to the public list, since we've gotten away from
discussing anything related to specific chips...]

> Date: Mon, 9 Jul 2001 12:43:06 -0400
> From: "Frank Ch. Eigler" <fche@redhat.com>

> : Can the bit numbering scheme be documented?  It's confusing to have an
> : option that says "make the LSB number 0" but have it actually do
> : something different.
> 
> It is documented somewhat.  See cgen/types.scm, "Bit ranges.".

I meant, can it be documented in the documentation?  I really don't
think writers of .cpu files should have to read every comment in cgen
to know what to do!

The docs currently say such things as:

word-bitsize
............
   
   The number of bits in a word.  In GCC, this is `BITS_PER_WORD'.

insn-lsb0?
..........

   Specifies whether the most significant or least significant bit in a
word is bit number 0.  Generally this should conform to the convention
in the architecture manual.  This is independent of endianness and is an
architecture wide specification.  There is no support for using
different bit numbering conventions within an architecture.


which is fine, but is it what is actually implemented?


> : > The lsb0=3D3D#f case makes that support unnecessary, in that bit number=
> ing
> : > is nice and linear.
> :=20
> : ???  I don't understand.  On a little-endian chip, if the MSB is
> : numbered 0, then the bit numbering will not really be `nice',
> : because the position of the MSB will vary with instruction length
> : and/or word size.
> 
> Endianness doesn't really enter it.  cgen doesn't deal with raw instruction
> bytes per se, but rather with byte sequences.  If bits are numbered from the
> left, then the left (leading) prefix will have have common bit numbers
> regardless of how long the instruction is.  The funny bit numbering
> scheme involved with lsb0=3D#t && variable-length is an effort to keep this
> image sort of working, but *is not implemented* fully/properly.

Aah, I see.  The instruction stream is divided up into _words_, and if
an instruction is a partial word, the .cpu file must be single-endian
and must assume the instruction is in the high bits (for big-endian) or
low bits (for little-endian) of the word?

It would probably help a lot if the "Instruction Fields" node of the
docs mentioned that in the context of instructions, a "word" for lsb0?
is base-insn-bitsize---at least, that's what the comments in types.scm
say:

; Instruction word sizes are based on the "base insn length" which is the
; number of bytes the cpu first looks at to decode an insn.

-- 
- Geoffrey Keating <geoffk@geoffk.org>