Re: exposed pipeline patch (long!)

[Doug Evans <dje@transmeta.com>]

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.