This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: variable length insns
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.