From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2971 invoked by alias); 19 Feb 2007 03:39:46 -0000 Received: (qmail 2963 invoked by uid 22791); 19 Feb 2007 03:39:45 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO elsdt-razorfish.arc.com) (194.202.198.226) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Feb 2007 03:39:38 +0000 Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l1J3chAx032316; Mon, 19 Feb 2007 03:38:43 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l1J3ch3F032314; Mon, 19 Feb 2007 03:38:43 GMT Date: Mon, 19 Feb 2007 03:39:00 -0000 From: Joern Rennecke To: Dave Brolley Cc: "Frank Ch. Eigler" , cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops Message-ID: <20070219033843.GA31910@elsdt-razorfish.arc.com> 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> <45D34205.9000209@redhat.com> <20070214182926.GA18550@elsdt-razorfish.arc.com> <45D36856.8010208@redhat.com> <20070214201406.GD18550@elsdt-razorfish.arc.com> <45D619DD.7010602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D619DD.7010602@redhat.com> User-Agent: Mutt/1.4.1i 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/msg00053.txt.bz2 On Fri, Feb 16, 2007 at 03:53:49PM -0500, Dave Brolley wrote: > Joern Rennecke wrote: > >On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote: > > > >>Joern Rennecke wrote: > >> > >>>That is indeed the case. The only format differences are in the > >>>RC-ilink / RC-noilink operand and in the F0 / F1F operand. > >>> > >>> > >>> > >>If so, then there must be more bits which are constant in each of the > >>two forms of the insn, otherwise, how does the hardware decode them? > >> > > > >ilink1 is core register 29, ilink2 is core register 30 . > >Thus, you could describe the upper four bits of RC-ilink as 7, > >but that would still not disambiguate it from RC-noilink for core registers > >28 and 31. > > > I would merge the two insns into one and handle the difference in the > semantic code by checking (index-of ) These insns have different syntax. I.e. the RC-ilink variant has an optional operand which the RC-noilink version hasn't. AFAIK this can not be expressed in cgen with a single insn. > >>>It's the same situation with long immediates. They are indicated by a > >>>special value in any one of three operand fields. > >>> > This could be handled in the same way by checking the values of the > immediate operands. You don't seem to quite understand the situation. I have to check the value of zero, one or two register fields in order to determine if the long immediate field exists. Therefore, I had to put part of the instruction fetch (the reading of the long immediate) in the semantics of the instruction. The knowledge about the instruction length is no longer in format field of insn patterns in the .cpu file, but in mloop*.in . With the length information already broken, I've also worked around the decoder generator problem with generating negative shifts by pretending that every instruction is 32 bit long; mloop*.in knowshaw to calculate that actual lengths and how to fetch 16 and 32 bit opcodes, and represent them as 32 bit opcodes.