From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23826 invoked by alias); 21 Sep 2005 15:39:55 -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 23192 invoked by uid 22791); 21 Sep 2005 15:39:12 -0000 Received: from neon-gw-l3.transmeta.com (HELO neon-gw.transmeta.com) (63.209.4.196) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 21 Sep 2005 15:39:12 +0000 Received: from victor.transmeta.com (victor.transmeta.com [10.0.2.120]) by neon-gw.transmeta.com (Postfix) with ESMTP id 970085F8047; Wed, 21 Sep 2005 08:39:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.transmeta.com (Postfix) with ESMTP id 6C6834F8032; Wed, 21 Sep 2005 08:39:09 -0700 (PDT) Received: from victor.transmeta.com ([127.0.0.1]) by localhost (victor [127.0.0.1]) (amavisd-new, port 10022) with LMTP id 16756-19; Wed, 21 Sep 2005 08:39:09 -0700 (PDT) Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by victor.transmeta.com (Postfix) with ESMTP id 1FEA94F8030; Wed, 21 Sep 2005 08:39:09 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.11.6/8.11.6) id j8LFd8Q17885; Wed, 21 Sep 2005 08:39:08 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17201.32412.843359.538250@casey.transmeta.com> Date: Wed, 21 Sep 2005 15:39:00 -0000 To: "Will Newton" Cc: "Frank Ch. Eigler" , Subject: RE: Constraints between operands In-Reply-To: <0D107966AF6D79418315B7C5549F4B5104DFDF@lemail1.le.imgtec.org> References: <0D107966AF6D79418315B7C5549F4B5104DFDF@lemail1.le.imgtec.org> X-SW-Source: 2005-q3/txt/msg00032.txt.bz2 Will Newton writes: > > > > [...] > > > I'm using cgen to write a binutils port for a processor. I've come > > > across a problem I haven't been able to solve yet with expressing a > > > constraint between a number of fields in an instruction. > > > [...] > > > ADD D0.1,D0.2 ; Data unit 0 for both regs, OK ADD D0.1,D1.2 ; Data > > > unit mismatch, error! > > > [...] > > > > One way may be to write a custom operand parser for the > > second D slot, which would enforce this constraint. It would > > signal a parse error. Another alternative I've seen is to specify a special operand at the end whose sole purpose is to validate the insn. It's at the end so it has a view of the entire insn. > I could not see an easy way to reference a previous field. The prototype > of parse handlers is like: > > static const char * > parse_hi16 (cd, strp, opindex, valuep) > CGEN_CPU_DESC cd; /* CPU description */ > const char **strp; /* Current position in input > text */ > int opindex; /* ??? */ > unsigned long *valuep; /* Result */ > > In order to find what the previous operand's data unit was the only way > I can see is to rewind strp and parse the input text, which may or may > not work and seems quite nasty. Or is there an easier way? I was going to say have either a special "parse" or "insert" handler. I seem to recall other instances where I needed to validate two operands against each other, but I can't find one at the moment. At any rate, you're right, the parse handler isn't passed sufficient info. If I can't find an existing example I think we need to extend cgen. e.g. pass the fields struct to either or both of the parse and insert handlers. Comments folks?