From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1461 invoked by alias); 25 Nov 2002 05:08:54 -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 1453 invoked from network); 25 Nov 2002 05:08:53 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 25 Nov 2002 05:08:53 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id VAA16190; Sun, 24 Nov 2002 21:08:40 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma016180; Sun, 24 Nov 02 21:08:14 -0800 Received: from xris-athlon.transmeta.com (xris-athlon.transmeta.com [10.10.25.96]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gAP58JR16933; Sun, 24 Nov 2002 21:08:19 -0800 (PST) Received: (from dje@localhost) by xris-athlon.transmeta.com (8.9.3/8.7.3) id VAA09731; Sun, 24 Nov 2002 21:08:19 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15841.45123.655171.135406@xris-athlon.transmeta.com> Date: Sun, 24 Nov 2002 21:08:00 -0000 To: "Jie Zhang" Cc: "Frank Ch. Eigler" , Subject: Re: Require some enhancement in CGEN for decoder of disassember In-Reply-To: References: <20021122161158.C1160@redhat.com> X-SW-Source: 2002-q4/txt/msg00036.txt.bz2 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.