🚀 go-pugleaf

In article <1992Dec12.102403.1@zodiac.rutgers.edu>  
leichter@zodiac.rutgers.edu writes:
> History repeats itself?  Many early RISC designs chose to expose timing  
and
> pipeline constraints to the software.  It was up to software not to access
> data before it arrived, for example.
> 
> Successive generations of RISC designs have moved that responsibility back  
to
> hardware.  The original Stanford MIPS had no pipeline interlocks at all -  
if
> the software didn't play by ALL the rules, it got nonsense.  The first
> generation of the commercial MIPS architecture cut the constraints down to
> two:  You had to wait one extra cyle before trying to use the results of a
> load or a multiply, if I remember right.  The second generation of  
commercial
> MIPS has even added hardware interlocks for those.

First off, even the Stanford MIPS project interlocked on cache misses for  
loads. (Its not really possible to build a processor that works without  
this.) Hence I consider the "no interlocks" line bogus. Secondly, the  
commercial MIPS I ISA has a load delay slot and a branch delay slot.  
(Multiply/divide is interlocked.) Good arguments for these are along the  
lines that you will not build machines that execute dependent instructions  
back to back in these cases and software (i.e. compilers) can easily handle  
them. The load delay slot has an impact on code density though and hence was  
removed.

> Delayed branches were a great idea for a while, but recent designs, such  
as
> Alpha, have eschewed them.

Without any real compelling arguments that I've heard. (Dick Sites saying  
"Any architecture with a 25 year life span won't have delayed branches." is  
not a compelling argument.) Note that such decisions depend a lot on other  
elements of your architecture. (E.g. compare-and-branch instructions vs.  
condition codes.) Delayed branches may be a win for one architecture but not  
for another.

> The IBM RS/6000 design has NO "correctness" constraints - the RISC-style
> optimizations are important for performance, but even without them the  
program
> runs.

There are correctness constraints for some of the privelleged instructions  
on the original RS/6000. Delayed instructions are not a major cause of  
program errors anyway though. On MIPS systems, the assembler takes care of  
it all for you so it just doesn't matter.

> Now we are trying the same thing with memory consistency.  Ten years from  
now,
> will we be looking back at those funny experiments of the early '90's that
> (a) made the machines such a bitch to program; and (b) didn't really help
> beyond a generation or two of design anyway?
> 							-- Jerry

As I said above, single delay slots do not make a machine "a bitch to  
program." It comes down to a performance analysis. You win with delayed  
branches unless you are going to throw a fair bit of hardware at instruction  
prefetching, in which case delayed branches don't matter one way or the  
other.

The issues for memory consistiency are quite different though. First of all,  
we a generally talking about tens or hundreds of cycles instead of one or  
two. Secondly it is more difficult to predict data access patterns in  
concurrent code than pipeline stall behavior. (Note that software controlled  
caching has been seriously studied as well and suffers similar problems.) 

One problem with software controlled memory synchronization is any barrier  
instructions you insert eat instruction issue bandwidth. Hence its easy to  
lose any gains you would get by having simpler/faster hardware.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson