Require some enhancement in CGEN for decoder of disassember

Require some enhancement in CGEN for decoder of disassember

[Jie Zhang]

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.
A and B can be distinguished only by this field.
In insn A, the value of the operand can range from 0 through 14.
If this field is 15, then the insn is B.
If I put the description of insn A before B, insn B is always
disassembled as insn A with the wrong operand value 15.
I can solve this problem by putting the description fo insn B before A,
but this is not a good solution.
I wish CGEN can deal with this issue.

-Jie Zhang

Re: Require some enhancement in CGEN for decoder of disassember

[Frank Ch. Eigler]

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

Re: Require some enhancement in CGEN for decoder of disassember

[Jie Zhang]

----- 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

Re: Require some enhancement in CGEN for decoder of disassember

[Doug Evans]

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.

Re: Require some enhancement in CGEN for decoder of disassember

[Jie Zhang]

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

> 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.
>

Yes, I need such a mechanism. I defined a derived operand, since ifield
assertions
can only be used with them. I defined an anyof operand using the derived
operand.
But this didn't work. I tried to find the reason. But I cannot find the
predicate and the
place where it is used.

-Jie

Re: Require some enhancement in CGEN for decoder of disassember

[Jie Zhang]

----- Original Message ----- 
From: "Jie Zhang" <jzhang918@hotmail.com>
To: <cgen@sources.redhat.com>

> I can solve this problem by putting the description fo insn B before A,
> but this is not a good solution.

Sorry. The problem actually cannot be solved by changing these
two insns order. I cannot find out why the problem could be
solved by changing the order at that time. Maybe I used a
different test case.

I find that CGEN will arrange the order of insns in the same
hash chains by the number of decodable bits in decreasing
order. That's the reason that the problem cannot be solved by
reordering the insns.

I search the cgen mailing list archive. And find

http://sources.redhat.com/ml/cgen/2001-q4/msg00026.html

gave the patch of ordering insns in hash chain.
But this patch give the wrong result in my case.
In my case the insn with less decodable bits is intended be
tried first, but CGEN puts it after the insns with more
decodable bits.

Is there a method turn off this reordering?
Has the ifield-assertion been implemented now? It is said
a todo item in

http://sources.redhat.com/ml/cgen/2001-q4/msg00032.html


-Jie