Re: cgen/gas: some support for funny-endian instruction sets

[Doug Evans <dje at transmeta dot com>]

Frank Ch. Eigler writes:
 > If parameters are not used (and there
 > are a bunch), IMO it is harmful to specify them.  They are untestable
 > decorations.  They lead to blind copying from port to port, there
 > being WIP documentation, no useful definition, no apparent harm
 > ... until cgen starts supporting it.  Then, instead of a
 > cgen-generation-time error ("missing parameter"), one gets a silently
 > buggy toolchain.

One recognizes this going in.  But in the context of word-bitsize
I can't quite get that anal over it.  In the context of something more
complex I'd tend to agree.

 > : Some more thoughts ...
 > : 
 > : In the beginning I played with whether or not to explicitly specify
 > : instruction formats.  Once you know an instruction's format, you
 > : know how to chunk up its elements.
 > 
 > Well, that's only true if it's circular: if the insn format
 > representation accounts for chunking, then yes, it does.  It doesn't
 > have to.  Several insn format lists I have seen in processor
 > documentation don't cover this, treating endianness/chunking as a
 > separate matter elsewhere (since it's an aspect of the processor's
 > physical data bus).

Ah.  Then I don't have a problem with the patch _providing_
word[-_]bitsize is renamed (say insn[-_]word[-_]bitsize).

 > For example:  word-bitsize=16, base-insn-size=32
 > insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
 > insn-word=0x3210     -EB=>0x32 0x10           -EL=>0x10 0x32

Why isn't base-insn-size 16?