Re: variable length insns

[Ben Elliston <bje at redhat dot com>]

Hi Doug,

>>>>> "Ben" == Ben Elliston <bje@redhat.com> writes:

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

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'.  What is a good plan of attack for handling
operand bits beyond the base insn?

Thanks.

Ben