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
- From: "Jie Zhang" <zhangjie at magima dot com dot cn>
- To: <cgen at sources dot redhat dot com>
- Date: Wed, 27 Nov 2002 15:46:35 +0800
- Subject: Re: Require some enhancement in CGEN for decoder of disassember
- References: <DAV29qgES6IGIkzryYJ00009cfe@hotmail.com>
----- 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