home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10483 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.0 KB  |  41 lines

  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!saimiri.primate.wisc.edu!caen!destroyer!gumby!yale!yale.edu!ira.uka.de!smurf.sub.org!incom!orfeo!qb!vhs
  3. From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
  4. Subject: RISC goes CISC?
  5. Message-ID: <1992Nov6.092012.19239@rhein-main.de>
  6. Sender: vhs@rhein-main.de (Volker Herminghaus-Shirai)
  7. Reply-To: vhs@rhein-main.de
  8. Date: Fri, 6 Nov 92 09:20:12 GMT
  9. Lines: 30
  10.  
  11. I was wondering lately...
  12. Wasn't one of the principles of RISC the principle of putting as much work
  13. as possible from execution to compile time?
  14. Under this assumption, how does e.g. SuperSPARC fit this principle? As far
  15. as I know the processor does a lot of cross-checking between pipelines,
  16. squashing instructions depending on non-trivial conditions, etc. Is that done
  17. just to maintain compatibility with previous implementations?
  18. Could, theoretically, the most recent compilers take care of this
  19. at compile-time, thus eliminating the need for run time
  20. checking (again theoretically since people want to run their old code).
  21. Wasn't the architectural(?) definition of using exactly one delay slot
  22. extremely short sighted, taking into account the much longer pipelines in
  23. current implementations?
  24. Aren't pipelines necessary so that instructions that take several cycles
  25. (i.e. "complicated" instructions) can be issued one per cycle? Wouldn't
  26. it conform more to the RISC principle to keep instructions so simple
  27. that they only *need* one cycle to execute and concentrate on a *fast*
  28. memory interface instead? Will RISC go the way that CISC went?
  29. Will PCs ever compare favorably to workstations? Will Jane marry Tarzan?
  30. Will this nonsense ever end? Will someone answer?
  31. ...
  32.  
  33. This is not meant to flame SPARC processors. They're just the RISC
  34. processor I know best (which does not say much, obviously).
  35.  
  36. --
  37. Volker Herminghaus-Shirai (vhs@rhein-main.de)
  38.  
  39. I'm a .signature antivirus. Help defend the net against the evil .signature
  40. viruses and copy me into your .signature file.
  41.