home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17380 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  4.3 KB
  1. Xref: sparky comp.sys.amiga.programmer:17380 comp.sys.amiga.hardware:21547
  2. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!uknet!edcastle!dcs.ed.ac.uk!jxp
  3. From: jxp@dcs.ed.ac.uk (Joe Potter)
  4. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
  5. Subject: Re: CISC and RISC
  6. Message-ID: <BzAxFw.Is6@dcs.ed.ac.uk>
  7. Date: 15 Dec 92 12:59:56 GMT
  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>
  9. Sender: cnews@dcs.ed.ac.uk (UseNet News Admin)
  10. Reply-To: jxp@dcs.ed.ac.uk (Joe Potter)
  11. Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
  12. Lines: 92
  13.  
  14. In article <1992Dec14.155039.7747@ugle.unit.no> skogaas@solan.unit.no (John Olav Skog}s) writes:
  15. >RISC - reduced instruction set computer:
  16. >
  17. >Fewer and less complex intructions than in CISC processors
  18.  
  19.     Fewer and sometimes MORE complex, surely?  Each instruction is very
  20. simple in its operation, but takes a complicated parameter.  Look at the
  21. ARM series for a worst-case scenario!
  22.  
  23. >Only one or two instruction formats (usually - results in fast decoding)
  24. >Large register file: 32-2048 internal registers
  25. >Few adressing modes (1-2 usually)
  26.  
  27.     Several for Load/Store Main Memory operations, few internal ones
  28. because there's only so much you can do with Reg <op> Reg to Reg!
  29.  
  30. >Optimizing compilers (it is easy to generate good code for the RISC
  31. >architecture)
  32.  
  33.     Actually, I'm of the understanding that current compiler
  34. technology is rather left behind by the sheer complexity of RISC coding.
  35. It's easy to generate code for RISC machines, but getting turbopowered
  36. optimisations is hard.  CISC is easier to optimise.
  37.  
  38. >Support for high-level languages (when it comes to passing parameters etc.)
  39.  
  40.     I doubt it's that much better than CISC, just in keeping with
  41. the RISC philosophy (which is the old line about 20% of the instructions
  42. doing 80% of the code, so provide only 20% of a useable instruction set
  43. :-)
  44.  
  45. >Hard-wired control unit
  46.  
  47.     As distinct from microcoded control?  Hmm... What did the 6510
  48. use?  Probably microcode as well, actually.
  49.  
  50. >Optimized instruction pipeline
  51. >LOAD/STORE - architecture
  52.  
  53.     What's actually so good about this, by itself?  Given all the
  54. other parts of RISC philosophy, great, but as a point by itself?
  55.  
  56. >One clock-cycle pr. instruction
  57.  
  58.     Ideally.  More usually four cycles, but with a four stage pipeline.
  59.  
  60.  
  61. >CISC - complex instruction set computer:
  62. >
  63. >Has a big software base (Amiga, Mac, DOS...)
  64. >The newest CISC processors are now using RISC techniques to archieve
  65. >performance (partly hardwired control-units, and one clock-cycle pr.
  66. >instruction).  It may be easier to make op.sys.-software on a CISC processor.
  67.  
  68.     Source/destination operand address is more efficiently done via
  69. decoding circuitry anyway.  If the source and dest. are not part of the
  70. opcode, that's the way they are decoded.
  71.  
  72. >The code size for RISC-processors will usually be larger than it would be for a
  73. >CISC processor.
  74.  
  75.     RISC philosophy suggests that it won't be that much bigger.
  76.  
  77. >Nowadays, it seems like that the RISC and CISC-prosessors are approaching each
  78. >other. The manufacturers incorporate RISC-features in CISC-processors and 
  79. >visa versa.
  80.  
  81.     Yes, and hopefully the good points get copied, not the bad!
  82.  
  83.     Now perhaps we'll have something to do with the Amiga?
  84.  
  85.  
  86. >More interesting is multiprocessor-systems, with maybe thousands of processors.
  87. >Or just 16 68040's in a "hypercube" system. Such HyperCubes are at the moment
  88. >being developed at the Norwegian Institute of Technology. An early prototype,
  89. >16 i486 connected together (with local memory and disk), was capable to raytrace 
  90. >a picture much faster than any other HyperCube in the world (i think it was by 
  91. >a factor of 10). It was done in just a couple of seconds. Merging and sorting 
  92. >two files were done 10-100 times the performance of a big mainframe. This system 
  93. >was originally designed to be a fault-tolerant system, with at least two copies 
  94. >of every byte on different disks. What about an Amiga HyperCube with 8 68040 
  95. >processors with XX MB local memory...?  :-) However, AmigaDOS would then have
  96. >to be rewritten quite a lot... Another Amiga model: Amiga NevroNet... :-)
  97.  
  98.     You first!
  99.  
  100.                             Joe.
  101.                         Wondering why he didn't
  102.                         redirect this to the
  103.                         theory groups...
  104.  
  105. "I SAID I'd like to BUY you a CHICKEN-LEG!"
  106.