This is the mail archive of the mailing list for the CGEN project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Require some enhancement in CGEN for decoder of disassember

----- Original Message -----
From: "Frank Ch. Eigler" <>
To: "Jie Zhang" <>
Cc: <>

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]