From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12798 invoked by alias); 9 Jan 2003 18:36:36 -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 12791 invoked from network); 9 Jan 2003 18:36:36 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 9 Jan 2003 18:36:36 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id KAA26102; Thu, 9 Jan 2003 10:36:21 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma026092; Thu, 9 Jan 03 10:36:14 -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 h09IaG325051; Thu, 9 Jan 2003 10:36:16 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id KAA15695; Thu, 9 Jan 2003 10:36:16 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15901.49440.723598.323574@casey.transmeta.com> Date: Thu, 09 Jan 2003 18:36: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> X-SW-Source: 2003-q1/txt/msg00013.txt.bz2 Frank Ch. Eigler writes: > > dje wrote: > > > I have big problems with this patch. > > [...] > > > One must have compelling reasons for moving or putting application > > specific stuff into the non-application specific parts of cgen [...] > > Refering to APPLICATION in rtl-c.scm. Blech. > > > > > -(define-fn xop (estate options mode object) object) > > > +(define-fn xop (estate options mode object) > > > + (let ((delayed (assoc '#:delay (estate-modifiers estate)))) > > > + (if (and delayed > > > + (equal? APPLICATION 'SID-SIMULATOR) > > > + (operand? object)) > > 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. The new delay operator actually does > something, and when/if sim-side support is added, this rtl-c hack can > go away. IIRC, the old delay operator did nothing except signal that > an abstract delay slot exists for the instruction in whose RTL the > operator appears someplace. If someone is genuinely fond of this > meaning, then I propose renaming it to something else. Redhat can keep this as a local mod of course, but the FSF would never readily accept a target-specific hack like this to gcc (#ifdef TARGET_Z8000 in expr.c for example). I think the same principal should apply here. I don't think the situation is all that bleak though. First, we need to separate architecture description from application usage. RTL is all about abstract description. What are the ports in question? Can I see the rtl where the new `delay' is used? (Are they checked in?) If they're still under NDA I'm sure you can come up with an independent example of how one would write rtl with the new `delay'. [You'd have to do that anyway for anyone wanting to use the new `delay'.] Then let's compare it, at the rtl level, with the old delay, and go from there. I'm guessing the difference is that the existing delay specifies when an assignment happens (more or less) and the new delay specifies when an operand is ready. If there is no reasonable way to merge them then clearly we need new rtl (assuming the new delay is for ISA-related delays and not implementation-related delays: I didn't get an answer to my question: for the ports that need this patch, are the delays ISA related or or implementation-related? I think you answered it in a previous message but I couldn't be sure).