From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20537 invoked by alias); 12 Jan 2003 17:05:40 -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 20530 invoked from network); 12 Jan 2003 17:05:40 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 12 Jan 2003 17:05:40 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA07518; Sun, 12 Jan 2003 09:05:26 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma007505; Sun, 12 Jan 03 09:05:08 -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 h0CH5A310387; Sun, 12 Jan 2003 09:05:10 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id JAA09659; Sun, 12 Jan 2003 09:05:10 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15905.41030.551684.625200@casey.transmeta.com> Date: Sun, 12 Jan 2003 17:05:00 -0000 To: fche@redhat.com (Frank Ch. Eigler) Cc: cgen@sources.redhat.com Subject: Re: exposed pipeline patch (long!) In-Reply-To: References: <15901.6554.376799.858742@casey.transmeta.com> <15901.49440.723598.323574@casey.transmeta.com> X-SW-Source: 2003-q1/txt/msg00018.txt.bz2 Frank Ch. Eigler writes: > > Can I see the rtl where the new `delay' is used? (Are they checked in?) > > [...] Here is a generic example: > > NEW: (if (test) (set (delay 1 foo) bar)) > OLD: (delay 1 (if (test) (set foo bar))) > > The new meaning makes "delay" a property of an lvalue being assigned > to as a future time (== enqueuing position). The old one relates > "delay" of a generic bunch of computation. The former definition is > sufficient to model ordinary branch delay slots, or functional units > that expose taking their sweet time. > The latter was never actually > implemented in a way a reader may expect: there is no delay in the > "if" or anything associated with foo or bar; there is no use of the > "1" value. For the purposes of this discussion (deciding whether the two delays are mergable) I'm separating description from application. I have this feeling that branch delay slots are a sufficiently different beast than the delays of exposed pipelines. Sure, one can argue the former is just an example of the latter. But there are various semantics associated with branch delay slots. OTOH, I don't have too strong an opinion I guess. So next question. The sid behaviour is special cased for fear of breaking existing ports (or some such IIRC). Presumably we can do a sufficiently reasonable job just by comparing generated files before/after (and in particular if in the first pass we take steps to remove all diffs in the generated files then the confidence goes up high enough for me to make the change). So _if_ delays are mergable and _if_ the new definition of delay is what we want, why not just go with it? [I still have questions of the implementation though (to follow).] > > [...] for the ports that need this patch, are the delays ISA related [...] > > These are ISA defined. > That's what makes the pipelines exposed to the asm programmer. An ISA might specify that the pipeline is exposed, but leave the actual delay to fall out from whatever the implementation ends up being. I wanted to make sure you're not talking about this case, and that you really want the delays in the rtl.