From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20702 invoked by alias); 14 Sep 2005 13:59:47 -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 20630 invoked by uid 22791); 14 Sep 2005 13:59:34 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 13:59:34 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j8EDxXpP027383 for ; Wed, 14 Sep 2005 09:59:33 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j8EDxWV10037; Wed, 14 Sep 2005 09:59:32 -0400 Received: from [127.0.0.1] (vpn50-158.rdu.redhat.com [172.16.50.158]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j8EDxRuT001303; Wed, 14 Sep 2005 09:59:30 -0400 Message-ID: <43282CBC.8090709@redhat.com> Date: Wed, 14 Sep 2005 13:59:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Will Newton CC: "Frank Ch. Eigler" , cgen@sources.redhat.com Subject: Re: Gas error messages References: <0D107966AF6D79418315B7C5549F4B5104DFF3@lemail1.le.imgtec.org> In-Reply-To: <0D107966AF6D79418315B7C5549F4B5104DFF3@lemail1.le.imgtec.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q3/txt/msg00028.txt.bz2 Will Newton wrote: > > > >The assembler I am writing supports a number of addressing modes, >expressed like: > >GET D0.0,[D0.1+D0.2] ; D0.0 <- mem[base(D0.1)+offset(D0.2)] >GET D0.0,[D0.1+#20] ; D0.0 <- mem[base(D0.1)+offset(20)] > >I have specified these a separate instrucions, e.g.: > >(dni ... > "GET $DataReg1,[$DataReg2+$DataReg3]" > ... >) >(dni ... > "GET $DataReg1,[$DataReg2+#$Immed]" > ... >) > >The immediate form is parsed by my custom parser, which returns it's >error message. However, it seems that cgen goes on to attempt to parse >the immediate as a register name, which fails with "unrecognized >keyword". Is there a way to control this behaviour? Once I have hit the >hash I would like to treat the value as always an immediate. > > This will happen once you finish implementing your parse function and it indicates "success" by returning NULL. Right now your parse function stub is indicating an error, so CGEN correctly attempts other parsing possibilities. Another thing to consider is that CGEN will attempt to parse the insn variants in the order in which they appear in the .cpu file (undocumented but relied on by several existing ports). You should be able to get the behaviour you want by defining the immediate form of the insn last. I hope this helps, Dave