Re: variable length insns

[Doug Evans <dje at transmeta dot com>]

Ben Elliston writes:
 > It seems that the
 > assumption thus far has been that the base-insn is the only place
 > where pre-determined opcode bits reside.

As far as the description language goes, no.
There is no such assumption.
I don't remember if any apps or ports make that assumption.

 > Having spent a fair amount of time trying to understanding the
 > problem, I've discovered this code in include/opcode/cgen.h:
 > 
 > 1.35         (devans   30-Nov-98): typedef struct
 > 1.35         (devans   30-Nov-98): {
 > 1.35         (devans   30-Nov-98):   /* The opcode portion of the base insn.  */
 > 1.35         (devans   30-Nov-98):   CGEN_INSN_INT base_value;
 > 1.35         (devans   30-Nov-98): 
 > 1.35         (devans   30-Nov-98): #ifdef CGEN_MAX_EXTRA_OPCODE_OPERANDS
 > 1.35         (devans   30-Nov-98):   /* Extra opcode values beyond base_value.  */
 > 1.35         (devans   30-Nov-98):   unsigned long ifield_values[CGEN_MAX_EXTRA_OPCODE_OPERANDS];
 > 1.35         (devans   30-Nov-98): #endif
 > 1.35         (devans   30-Nov-98): } CGEN_IVALUE;
 > 
 > Can you tell me what your intention was here (ie. why is
 > `ifield_values' an array)? I see no code elsewhere that attempts to
 > use `ifield_values'.

No port had needed it yet.
Following my usual style, I put something in as a form
of "getting it down on paper" to be revisited later when the time came.

 > What is a good plan of attack for handling
 > operand bits beyond the base insn?

Without having spent much time thinking about it,
what if you replaced unsigned long in ifield_values with char
(or unsigned char), and record the trailing opcode bytes as bytes?

Then you could build insns by a simple copy, followed by
operand processing.