variable length insns

[Doug Evans <dje at transmeta dot com>]

Ben Elliston writes:
 > Despite fche's "Eureka!" the other day, things still don't quite work
 > with respect to variable length instructions.  I currently have my
 > 16/32 bit ISA split thusly (insn-lsb0? #t):
 > 
 >       16          0  31        15
 >       +-----------+  +----------+
 >       | base-insn |  | optional |
 >       +-----------+  +----------+
 > 
 > In its internal representation (an int), should I expect the
 > instruction to be represented as (base_insn << 16) | optional?  Or
 > will it assume the correct bit order of 31 .. 0?  That's my first
 > question.

Trying to keep such insns in an int is problematic.
Dunno what the "correct" bit order should be in this context.
What would you want for a little vs big endian host?
For ISA's like these, just think of insns as a byte stream.

 > I realise this aspect of cgen is frought with danger, but I'd
 > appreciate any guidance in order to make the necessary enhancements.

I dunno about danger.

Suppose you take the route of not trying to keep a 32 bit insn
in an int (maybe ditto for 16 bit insns).