Re: exposed pipeline patch (long!)

[Doug Evans <dje at transmeta dot com>]

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).