home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10488 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.2 KB
  1. Path: sparky!uunet!littlei!hfglobe!chnews!chnews!doconnor
  2. From: doconnor@sedona.intel.com (Dennis O'Connor)
  3. Newsgroups: comp.arch
  4. Subject: Re: RISC goes CISC?
  5. Message-ID: <DOCONNOR.92Nov6164041@potato.sedona.intel.com>
  6. Date: 6 Nov 92 16:40:41 GMT
  7. References: <1992Nov6.092012.19239@rhein-main.de>
  8. Organization: Intel i960(tm) Architecture
  9. Lines: 61
  10. NNTP-Posting-Host: potato.intel.com
  11. In-reply-to: vhs@rhein-main.de's message of Fri, 6 Nov 92 09:20:12 GMT
  12.  
  13.  
  14. vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
  15. ] I was wondering lately...
  16. ] Wasn't one of the principles of RISC the principle of putting as much work
  17. ] as possible from execution to compile time?
  18.  
  19. A better idea is to have the compiler do what it can do well, and let
  20. the hardware do what it can do well. For example, compilers can do
  21. register lifetime analysis well, but hardware does a much better
  22. job handling interlocks from operations with variable completion times.
  23.  
  24. ] Under this assumption, how does e.g. SuperSPARC fit this principle? As far
  25. ] as I know the processor does a lot of cross-checking between pipelines,
  26. ] squashing instructions depending on non-trivial conditions, etc. Is that done
  27. ] just to maintain compatibility with previous implementations?
  28.  
  29. It's an implementation trying to be a correct interpretter of it's ISA
  30. ( Instruction Set Architecture ). Otherwise, binaries for one Sparc
  31. might not work on another Sparc.
  32.  
  33. ] Could, theoretically, the most recent compilers take care of this
  34. ] at compile-time, thus eliminating the need for run time
  35. ] checking (again theoretically since people want to run their old code).
  36.  
  37. Depends. Generally, scoreboarding in the hardware produces better
  38. performance ( when coupled with compiler reordering of the instructions
  39. to minimize time spent waiting for results ) than adding the worst-case
  40. number of No-ops ( which will vary from system-to-system ).
  41.  
  42. ] Wasn't the architectural(?) definition of using exactly one delay slot
  43. ] extremely short sighted, taking into account the much longer pipelines in
  44. ] current implementations?
  45.  
  46. Gack. Are we talking branch delays or load result-ready delays ? Longer
  47. pipelines often don't affect the branch anyway ( if it's done in
  48. it's own peice of special hardware ) altho pipelining the I-Cache
  49. or instruction decode will. It all depends. Personally, I don't
  50. like architecturally-defined delay slots anyway : there are usually
  51. ways to get rid of them ( speculative issue for branches, load
  52. queues with hardware interlocks for loads ).
  53.  
  54.  
  55. ] Aren't pipelines necessary so that instructions that take several cycles
  56. ] (i.e. "complicated" instructions) can be issued one per cycle?
  57.  
  58. Pipelines trade thruput for latency at the cost of complexity.
  59.  
  60. ] Wouldn't it conform more to the RISC principle to keep instructions so
  61. ] simple that they only *need* one cycle to execute and concent rate on a *fast*
  62. ] memory interface instead?
  63.  
  64. Actually, one of the claimed advantages of RISC architectures is that
  65. they are easy to pipeline. A machine with a 5-stage pipeline, if you
  66. took the pipelining out, would probably issue instructions at 1/3rd
  67. or so of it's original rate, due to it needing a much slower clock.
  68.  
  69. ] Will RISC go the way that CISC went?
  70.  
  71. RISC (in micros) went there (pipelined) first, actually.
  72. --
  73. Dennis O'Connor            doconnor@sedona.intel.com
  74.