From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26822 invoked by alias); 14 Feb 2007 18:30:01 -0000 Received: (qmail 26814 invoked by uid 22791); 14 Feb 2007 18:30:00 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.transmeta.com (HELO mx1.transmeta.com) (63.209.4.221) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Feb 2007 18:29:48 +0000 Received: from neon-gw-l3.transmeta.com (HELO neon-gw.transmeta.com) ([63.209.4.196]) by mx1.transmeta.com with ESMTP/TLS/AES256-SHA; 14 Feb 2007 10:29:46 -0800 X-IronPort-AV: i="4.14,170,1170662400"; d="scan'208"; a="2336925:sNHT24410404" Received: from victor.transmeta.com (victor.transmeta.com [10.0.2.120]) by neon-gw.transmeta.com (Postfix) with ESMTP id D4A455F803B; Wed, 14 Feb 2007 10:29:44 -0800 (PST) Received: from victor.transmeta.com (localhost.localdomain [127.0.0.1]) by victor.transmeta.com (Postfix) with ESMTP id 102843BF340; Wed, 14 Feb 2007 10:29:46 -0800 (PST) Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by victor.transmeta.com (Postfix) with ESMTP id 00D2D3BF33F; Wed, 14 Feb 2007 10:29:46 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.11.6/8.11.6) id l1EITjT14850; Wed, 14 Feb 2007 10:29:45 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17875.21785.589853.195295@casey.transmeta.com> Date: Wed, 14 Feb 2007 18:30:00 -0000 To: Joern Rennecke Cc: cgen@sources.redhat.com Subject: Re: delayed branches and zero overhead loops In-Reply-To: <20070213203746.GA16492@elsdt-razorfish.arc.com> References: <20070213153717.GA12710@elsdt-razorfish.arc.com> <17874.4229.806002.475024@casey.transmeta.com> <20070213203746.GA16492@elsdt-razorfish.arc.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid 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/msg00045.txt.bz2 Joern Rennecke writes: > On Tue, Feb 13, 2007 at 11:24:53AM -0800, Doug Evans wrote: > > It sounds like you want to add an application specific entry to the > > cpu description file. For me that's an ipso-facto wrong way to go. > > This is something only of concern to applications that care about the > semantics of the insns. Thus, gas does not need to know about this. Clearly. [And the chosen implementation is specific to the particular simulator you're writing.] > 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. 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. Having said that, I can envision providing the necessary specification along side setup-semantics, and then having the simulator make use of it. If done this way, the specification is of the architecture in a (hopefully) reasonably useful way and any app that wants to make use of the data can. > If you want it to frame it in terms that give universal meaning to the > instruction semantics, you can express it in three pieces: > - A piece of rtl that might need to be appeded to the semantics of > every instruction. > - A condition that tests if this piece of rtl should actually be > executed, for use in a simple interpreter. > - In the mloop.in:xextract-pbb code, code that computes at decode time > when to append the pseudo insn to a pbb > (or if you have some other use for a pseudo insn that doesn't end > a pbb, you might also stick it into the middle). Right, setting aside the last part. I'm not sure I'd do it that way, but I haven't been in that particular code for awhile. > > Thus question: Is there a way to express the zero-overhead > > loops in an a way that is more faithful to being just a > > description of the architecture, and not an application specific hack. > > As I said above, you can do it by adding rtl to every instruction that makes > every instruction COND_CTI. And (I think) we both agree this isn't the best way to go. > > Which leads to me next question: > > Is ARCompact a variant of the ARC for which I did a port ages ago? > > Unfortunately, the sourceware.org cvs history is a bit patchy - e.g. the > bfd cvs history only goes back to 1999 - so I'm not sure which part(s) > of the toolchain you ported, and to what ARC variant. lp_start, lp_end, lp_count sound very familiar, as does special casing of r62.