This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: Require some enhancement in CGEN for decoder of disassember
Jie Zhang writes:
> > On Thu, Nov 21, 2002 at 11:59:13AM +0800, Jie Zhang wrote:
> > > I encounter a problem when I'm using CGEN to port binutils.
> > > In my target, there is a rather strange 4-bit field.
> > > There are two insns, A and B. This field is operand in insn A,
> > > but opcode for insn B.
> > > [...]
> > > In insn A, the value of the operand can range from 0 through 14.
> > > If this field is 15, then the insn is B.
> > > [...]
> >
> > One way to model this with CGEN is to act like the operand/opcode
> > field is opcode only, by replicating instruction A 15 times, each
> > with a different value (0..14) for the problematic field. You
> > might also need some custom operand parsers to assert that each
> > variant of A will match only if the given logical operand matches
> > the actual one.
> >
> > If the only piece of the toolchain producing incorrect behavior is
> > the disassembler, you may also be able to make it work by turning
> > off disassembly hashing (#define CGEN_DIS_HASH(buf,value) 0).
>
> Thank you!
> The first method is not feasible, because the field acts as operand in
> all insns (about 30) but one. We would have 30 * 15 insn descriptions
> if we replicated each insn 15 times.
>
> We tried the second method. The situation became better. But there are still
> some insns disassembled incorrectly.
>
> I expect that CGEN can find out such operand and generate some code
> to deal with it.
Assuming I understand the issue correctly,
"ifield assertions" is the intended way to handle this.
[relevant insns have an additional predicate that is used
to assert whether a particular set of field values is ok]
If they don't work here then let's make them work.