From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22428 invoked by alias); 14 Feb 2007 19:22:57 -0000 Received: (qmail 22418 invoked by uid 22791); 14 Feb 2007 19:22:56 -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; Wed, 14 Feb 2007 19:22:46 +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 l1EJMWQ3019409; Wed, 14 Feb 2007 19:22:32 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l1EJMW1R019407; Wed, 14 Feb 2007 19:22:32 GMT Date: Wed, 14 Feb 2007 19:22:00 -0000 From: Joern Rennecke To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops Message-ID: <20070214192232.GC18550@elsdt-razorfish.arc.com> References: <20070213153717.GA12710@elsdt-razorfish.arc.com> <17874.4229.806002.475024@casey.transmeta.com> <20070213203746.GA16492@elsdt-razorfish.arc.com> <17875.21785.589853.195295@casey.transmeta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17875.21785.589853.195295@casey.transmeta.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/msg00048.txt.bz2 On Wed, Feb 14, 2007 at 10:29:45AM -0800, Doug Evans wrote: > Joern Rennecke writes: > > > If you wanted to generate a gcc machine description, than this is > > in principle relevant - except that expressing this all in generic rtl > > would likely lead the machine description generator to give up, > > since it won't be able to find any basic arithmetic instructions - > > every instruction will be flagged as having conditional flow control. > > I wouldn't add this specification to the insns. Blech. > I would add it to the same place where "condition" and "setup-semantics" is. Yes, that's a reasonable place to put the specification for the semantics when you are executing one insn at a time. Still, there should also be a way to streamline this with the pbb simulator. Note that trying to do this fully automatic would require a combination of profiling and artificial intelligence; you need to realize that, although loop_end can be changed at runtime, it is not likely to change all too often, so it makese sense to to the comparison at decode time, and invalidate any decoded pbb if a new loop end is placed inside it. FWIW, the condition part of the isa form is actually not usable for ARC, since not all instruction take the canonical condition. lpcc takes it, but it has a no-noop 'else' operation. A number of instructions take a different condition, or none at all. > No claim is made that new fields that are reasonable can't be added here. > > > > Having said that, I can imagine partitioning the description file > > > into multiple files such that these pseudo-insns are only seen by > > > the application in question. > > > > Why does it have to be yet another file? There is already a syntax-only > > attribute that specifies that some information is only for applications that > > care about syntax. > > Not that I am fundamentally opposed to doing it with separate files, > > but it appears to me that it makes things core complicated rather than > > simpler. > > There's no basic limit on the number of applications that can use cgen. > I would argue against a modus operandi that had the default behaviour > of adding such (obvious) application specific stuff to the basic > cpu description file. When working with libraries, programmers don't > think of modifying the library in their first pass at using it. > Same reasoning applies here. Then we'd need some mechanism to allow sem*switch.c to be built using application-specific fragments, so that the required pseudo instruction can be included in the switch. Would you also want to re-design the way the sh.cpu deals with the different delay slot mechanisms of sim and sid? It seems rather strange that delay slots have to be described in two languages at once.