home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17402 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  3.1 KB
  1. Xref: sparky comp.sys.amiga.programmer:17402 comp.sys.amiga.hardware:21588
  2. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
  3. Path: sparky!uunet!usc!cs.utexas.edu!torn!utgpu!engb
  4. From: engb@gpu.utcs.utoronto.ca (Ben Eng)
  5. Subject: Re: CISC and RISC
  6. Message-ID: <BzBtx4.DLE@gpu.utcs.utoronto.ca>
  7. Organization: Jet Penguin Lavatories
  8. References: <70436@cup.portal.com> <amipb.04wr@amipb.gna.org> <37844@cbmvax.commodore.com> <Bz8FD1.Dxt@ns1.nodak.edu> <1992Dec14.155039.7747@ugle.unit.no> <BzAxFw.Is6@dcs.ed.ac.uk>
  9. Date: Wed, 16 Dec 1992 00:41:27 GMT
  10. Lines: 61
  11.  
  12. In <BzAxFw.Is6@dcs.ed.ac.uk> jxp@dcs.ed.ac.uk (Joe Potter) writes:
  13.  
  14. >In article <1992Dec14.155039.7747@ugle.unit.no> skogaas@solan.unit.no (John Olav Skog}s) writes:
  15.  
  16. >>Optimizing compilers (it is easy to generate good code for the RISC
  17. >>architecture)
  18.  
  19. >    Actually, I'm of the understanding that current compiler
  20. >technology is rather left behind by the sheer complexity of RISC coding.
  21. >It's easy to generate code for RISC machines, but getting turbopowered
  22. >optimisations is hard.  CISC is easier to optimise.
  23.  
  24. I would like to see that statement qualified.
  25.  
  26. >>Hard-wired control unit
  27. >>Optimized instruction pipeline
  28. >>LOAD/STORE - architecture
  29.  
  30. >    What's actually so good about this, by itself?  Given all the
  31. >other parts of RISC philosophy, great, but as a point by itself?
  32.  
  33. The features are good because they allow for a "better", faster
  34. microprocessor.  The criteria for better are probably different for
  35. different people, but clock speed, pipelining, scalability,
  36. cost, the ability to be able to use new fab processes quickly,
  37. and such are considerations.
  38.  
  39. >>One clock-cycle pr. instruction
  40.  
  41. >    Ideally.  More usually four cycles, but with a four stage pipeline.
  42.  
  43. Nominal throughput of 1 inst/clock, with a latency of 4 clock cycles.
  44.  
  45. > It may be easier to make op.sys.-software on a CISC processor.
  46.  
  47. I consider that to be an incorrect statement.  The operating system
  48. is almost completely written in a language such as C or C++, just like
  49. most other applications.  If the compiler handles the translation
  50. well, where is the difficulty in generating code for RISC processors?
  51. I don't remember seeing volumes of articles, or hearing many complaints
  52. from RISC OS implementors about how difficult it is to generate code
  53. for RISC as opposed to CISC.
  54.  
  55.  
  56. It seems to me like your arguments against RISC are that it is more
  57. difficult to program from a software point of view.  Well the benefits
  58. you get are mostly embodied in the hardware improvements (speed,
  59. design, fab processes, scalability, and whatever else RISC chip
  60. companies deem important).  RISC vendors work closely with compiler
  61. implementors when designing the instruction sets.  Essentially, the
  62. machine interface for most software people becomes the compiled
  63. language.  I mean, as an asm programmer, would you really want to
  64. keep track of what values you have in 64 or more registers?  :-)
  65. So get rid of the asm programmers (or lock them up in a compiler
  66. vendor's lab) and everyone will be pretty happy.
  67.  
  68. Ben
  69. -- 
  70. e-mail: engb@gpu.utcs.utoronto.ca or ben@jetpen.gts.org (Ben Eng)
  71. UofT EngSci 9T2                   ``We are all masochists here.''
  72. Home: (416)-979-8761, (416)-979-7885
  73.