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

[Doug Evans <dje at transmeta dot com>]

Frank Ch. Eigler writes:
 > The patch below gives an interpretation to the hitherto-unused
 > cgen "word-bitsize" CPU parameter.  It is interpreted to mean
 > the chunking size for endianness conversions when processing
 > long instructions.  When this parameter is set smaller than
 > "base-insn-size" or happens to be smaller than the length of an
 > instruction, then the instruction bytes are chunked into
 > "word-bitsize" units, and individually endianness-converted.
 > 
 > 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
 > 
 > The support for this is incomplete.  Among the missing:
 > * simulator support (insn fetch/decode)
 > * non-INT_INSN_P target support
 > but it's a first step.
 > 
 > The patch is not intended to affect existing ports; I tested a bunch
 > of them both with and without opcodes/ regeneration.
 > 
 > In the absence of objections, I plan to commit this shortly.

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.
I think the jury is still out but cgen has gotten by without
explicitly specifying them this far.  In the beginning an architecture
may have a few simple formats, but it often doesn't stay that way.
And when writing .cpu files having to match an instruction with its
format is cumbersome (aka error prone).  Thus they're currently
machine generated.

So some questions:
Setting aside the issue of how instruction formats
are specified, if you had access to the instruction's format,
would that assist in solving your problem?  Do you think a
more appropriate solution would be found by going down this path?