From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1008 invoked by alias); 14 Feb 2007 17:09:08 -0000 Received: (qmail 996 invoked by uid 22791); 14 Feb 2007 17:09:07 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Feb 2007 17:08:50 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1EH8eE1028125; Wed, 14 Feb 2007 12:08:44 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1EH8Yjf016288; Wed, 14 Feb 2007 12:08:36 -0500 Received: from [10.11.14.175] (vpn-14-175.rdu.redhat.com [10.11.14.175]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1EH8Nrv019553; Wed, 14 Feb 2007 12:08:26 -0500 Message-ID: <45D34205.9000209@redhat.com> Date: Wed, 14 Feb 2007 17:09:00 -0000 From: Dave Brolley User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) MIME-Version: 1.0 To: Joern Rennecke CC: "Frank Ch. Eigler" , cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops References: <20070213153717.GA12710@elsdt-razorfish.arc.com> <20070213185118.GA20088@redhat.com> <20070213205905.GB16492@elsdt-razorfish.arc.com> <20070213211152.GD20088@redhat.com> <20070213222044.GA31512@elsdt-razorfish.arc.com> In-Reply-To: <20070213222044.GA31512@elsdt-razorfish.arc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00044.txt.bz2 Joern Rennecke wrote: >On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote: > > >>The decoder generator is fully automatic. If you represent decodable >>bits without cheating, it will do a reasonable job. >> >> > >I which that were the case. Try to generate the decoder for the attached >file; it warns about one alledged Decoder ambiguity for j_L_r_r [$RC-noilink] >versus j_L_r_r [$RC-ilink] . The values for $RC-ilink and $RC-noilink are >disjoint. I've also tried to use a decode-split on this problem, but to >no avail. > > The problem is that RC-ilink and RC-noilink are operands. They do not participate in insn decoding. If there are no other differences in the fixed fields of the insns (it's hard to tell because of the complexity of your pmacros), then there will be an ambiguity. If you add enough "-v"s to CGENFLAGS when you run your make, you will get a dump of the pmacro-expanded input. Dave