Re: Require some enhancement in CGEN for decoder of disassember

["Jie Zhang" <jzhang918@hotmail.com>]

----- Original Message -----
From: "Frank Ch. Eigler" <fche@redhat.com>
To: "Jie Zhang" <jzhang918@hotmail.com>
Cc: <cgen@sources.redhat.com>


> Hi -
>
> 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).
>
>
> - FChE
>

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.

-Jie Zhang