variable length insns

[Ben Elliston <bje at redhat dot com>]

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.

The second question pertains to assembly.  It seems that the
assumption thus far has been that the base-insn is the only place
where pre-determined opcode bits reside.  In my port, this is not
true.  The 32-bit instructions also contain fixed opcode bits in the
extended part of the instruction word.  In assembly, the insn is built
by extracting the base-insn value and then populating the operands
(see insert_insn_normal() for the details).  Is my assumption correct?

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

Ben