From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28498 invoked by alias); 12 Jan 2003 17:21:44 -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 28490 invoked from network); 12 Jan 2003 17:21:44 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 12 Jan 2003 17:21:44 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA08057; Sun, 12 Jan 2003 09:21:30 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma008053; Sun, 12 Jan 03 09:21:27 -0800 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h0CHLU310976; Sun, 12 Jan 2003 09:21:30 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id JAA09696; Sun, 12 Jan 2003 09:21:29 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15905.42009.962772.62733@casey.transmeta.com> Date: Sun, 12 Jan 2003 17:21:00 -0000 To: graydon hoare Cc: cgen public list Subject: Re: exposed pipeline patch (long!) In-Reply-To: <1042139501.884.172.camel@dub.venge.net> References: <15901.6554.376799.858742@casey.transmeta.com> <1042139501.884.172.camel@dub.venge.net> X-SW-Source: 2003-q1/txt/msg00019.txt.bz2 graydon hoare writes: > On Thu, 2003-01-09 at 12:55, Frank Ch. Eigler wrote: > > > I believe this was added with good intentions: because the "delay" > > operator name was already in some token use for older sim ports, and > > we did not want to break them. > > yes. the semantics were enhanced to a superset of those in "sim" common. > unfortunately rtl trees seem to be given a fixed operational semantics > in terms of the C code they generate. there is, from my limited > understanding, no other place in which an application is *able* to alter > interpretation of the (delay...) rtl node, or its sub-nodes, without > replacing parts of "the" rtl-evaluator. > > I certainly would have liked to put all these changes in *-sid.scm, I > just didn't find any practical way to do so. any suggestions? Adding hooks in various places for applications to use is something I've thought about. Have wanted to postpone doing so until the need was compelling. OTOH, as long as the internal rtl records what's in the .cpu file, it's up to the file generators to deal with interpretation of the rtl. File generators shouldn't be thinking they need to "alter interpretation" while rtl is being processed by cgen-proper. cgen-proper records some basic things while processing rtl, but that's it.