home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11589 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  1.8 KB
  1. Path: sparky!uunet!gatech!rpi!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!rutgers!igor.rutgers.edu!zodiac.rutgers.edu!leichter
  2. From: leichter@zodiac.rutgers.edu
  3. Newsgroups: comp.arch
  4. Subject: <None>
  5. Message-ID: <1992Dec12.102403.1@zodiac.rutgers.edu>
  6. Date: 12 Dec 92 15:24:03 GMT
  7. References: <Bz0xLu.298v@austin.ibm.com> <1g86boINNh5m@fido.asd.sgi.com> <lifvl6INNan3@exodus.Eng.Sun.COM> <1gb2dfINNspg@pollux.usc.edu>
  8. Sender: news@igor.rutgers.edu
  9. Organization: Rutgers University Department of Computer Science
  10. Lines: 24
  11. Nntp-Posting-Host: pisces.rutgers.edu
  12.  
  13. History repeats itself?  Many early RISC designs chose to expose timing and
  14. pipeline constraints to the software.  It was up to software not to access
  15. data before it arrived, for example.
  16.  
  17. Successive generations of RISC designs have moved that responsibility back to
  18. hardware.  The original Stanford MIPS had no pipeline interlocks at all - if
  19. the software didn't play by ALL the rules, it got nonsense.  The first
  20. generation of the commercial MIPS architecture cut the constraints down to
  21. two:  You had to wait one extra cyle before trying to use the results of a
  22. load or a multiply, if I remember right.  The second generation of commercial
  23. MIPS has even added hardware interlocks for those.
  24.  
  25. Delayed branches were a great idea for a while, but recent designs, such as
  26. Alpha, have eschewed them.
  27.  
  28. The IBM RS/6000 design has NO "correctness" constraints - the RISC-style
  29. optimizations are important for performance, but even without them the program
  30. runs.
  31.  
  32. Now we are trying the same thing with memory consistency.  Ten years from now,
  33. will we be looking back at those funny experiments of the early '90's that
  34. (a) made the machines such a bitch to program; and (b) didn't really help
  35. beyond a generation or two of design anyway?
  36.                             -- Jerry
  37.