This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: variable length insns
- To: dje at transmeta dot com, cgen at sources dot redhat dot com
- Subject: Re: variable length insns
- From: Ben Elliston <bje at redhat dot com>
- Date: Wed, 28 Mar 2001 17:06:18 +1000 (EST)
- References: <15041.7535.134168.721180@scooby.apac.redhat.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