[RFA:] Fix lsb? bug with insn fields beyond base insn size.

[Doug Evans <dje@transmeta.com>]

Hans-Peter Nilsson writes:
 > This is a partial fix for what seems like a central problem:
 > bitfields are expressed as (start length) but whether "start" is
 > highest or lowest bit-number depends on "lsb0?".  It looks like
 > that's an ungood design choice and causes several bugs, two
 > fixed below, I hope.  (The "bitrange-overlap?" thingy looks
 > harmless though).  If anyone would ask, I'd say convert all
 > bit-field numbering to be as for the lsb0? #f case: a bitfield
 > specified as (dnf f-op "" () 0 3) always starts at 0 and is 3
 > bits long everywhere, regardless of lsb0?.

One recognizes these issues going in.
One problem to consider is whether the .cpu writer
can enter the data using the numbering scheme found in the architecture
manual, or whether s/he has to translate to cgen's scheme.

Certainly .cpu derived machine generated documentation
should match the architecture manual, but that can be done
at document generation time.  The issue then becomes one
of maintenance.  Are people willing to put up with having
to continually do the translation for cpu's that happen
to pick the "wrong" (1/2 :-) numbering scheme.  And when they
make mistakes will they also argue there's a bug?

One alternative is to do the canonicalization at .cpu reading time,
but that can also lead to confusion (causing people to revisit
the issue again).

I'm not fixed on the current scheme, but it shouldn't change without
a full discussion and buy-in from people on the list.

It'll take a day to study the patch.