From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25886 invoked by alias); 9 Jan 2003 17:55:48 -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 25846 invoked from network); 9 Jan 2003 17:55:47 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 9 Jan 2003 17:55:47 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9DB8D8000E7; Thu, 9 Jan 2003 12:55:35 -0500 (EST) Received: (from fche@localhost) by toenail.toronto.redhat.com (8.11.6/8.11.6) id h09HtGw25297; Thu, 9 Jan 2003 12:55:16 -0500 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Doug Evans Cc: cgen@sources.redhat.com Subject: Re: exposed pipeline patch (long!) References: <15901.6554.376799.858742@casey.transmeta.com> Content-Type: text/plain; charset=US-ASCII From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 09 Jan 2003 17:55:00 -0000 In-Reply-To: <15901.6554.376799.858742@casey.transmeta.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2003-q1/txt/msg00012.txt.bz2 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. - FChE