From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24487 invoked by alias); 27 Nov 2002 07:47:09 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 24451 invoked from network); 27 Nov 2002 07:46:43 -0000 Received: from unknown (HELO www6.chinadns.com) (211.154.211.69) by sources.redhat.com with SMTP; 27 Nov 2002 07:46:43 -0000 Received: (qmail 78287 invoked from network); 27 Nov 2002 07:46:31 -0000 Received: from unknown (HELO zhangj0113) (zhangjie@magima.com.cn@unknown) by unknown with SMTP; 27 Nov 2002 07:46:31 -0000 Message-ID: <008b01c295e9$1d2de1e0$2c00000a@sh.magima.com> From: "Jie Zhang" To: References: Subject: Re: Require some enhancement in CGEN for decoder of disassember Date: Tue, 26 Nov 2002 23:47:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2002-q4/txt/msg00039.txt.bz2 ----- Original Message ----- From: "Jie Zhang" To: > 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