From: jxp@dcs.ed.ac.uk (Joe Potter)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 15 Dec 92 12:59:56 GMT
Reply-To: jxp@dcs.ed.ac.uk (Joe Potter)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <1992Dec14.155039.7747@ugle.unit.no> skogaas@solan.unit.no (John Olav Skog}s) writes:
>RISC - reduced instruction set computer:
>
>Fewer and less complex intructions than in CISC processors

	Fewer and sometimes MORE complex, surely?  Each instruction is very
simple in its operation, but takes a complicated parameter.  Look at the
ARM series for a worst-case scenario!

>Only one or two instruction formats (usually - results in fast decoding)
>Large register file: 32-2048 internal registers
>Few adressing modes (1-2 usually)

	Several for Load/Store Main Memory operations, few internal ones
because there's only so much you can do with Reg <op> Reg to Reg!

>Optimizing compilers (it is easy to generate good code for the RISC
>architecture)

	Actually, I'm of the understanding that current compiler
technology is rather left behind by the sheer complexity of RISC coding.
It's easy to generate code for RISC machines, but getting turbopowered
optimisations is hard.  CISC is easier to optimise.

>Support for high-level languages (when it comes to passing parameters etc.)

	I doubt it's that much better than CISC, just in keeping with
the RISC philosophy (which is the old line about 20% of the instructions
doing 80% of the code, so provide only 20% of a useable instruction set
:-)

>Hard-wired control unit

	As distinct from microcoded control?  Hmm... What did the 6510
use?  Probably microcode as well, actually.

>Optimized instruction pipeline
>LOAD/STORE - architecture

	What's actually so good about this, by itself?  Given all the
other parts of RISC philosophy, great, but as a point by itself?

>One clock-cycle pr. instruction

	Ideally.  More usually four cycles, but with a four stage pipeline.


>CISC - complex instruction set computer:
>
>Has a big software base (Amiga, Mac, DOS...)
>The newest CISC processors are now using RISC techniques to archieve
>performance (partly hardwired control-units, and one clock-cycle pr.
>instruction).  It may be easier to make op.sys.-software on a CISC processor.

	Source/destination operand address is more efficiently done via
decoding circuitry anyway.  If the source and dest. are not part of the
opcode, that's the way they are decoded.

>The code size for RISC-processors will usually be larger than it would be for a
>CISC processor.

	RISC philosophy suggests that it won't be that much bigger.

>Nowadays, it seems like that the RISC and CISC-prosessors are approaching each
>other. The manufacturers incorporate RISC-features in CISC-processors and 
>visa versa.

	Yes, and hopefully the good points get copied, not the bad!

	Now perhaps we'll have something to do with the Amiga?


>More interesting is multiprocessor-systems, with maybe thousands of processors.
>Or just 16 68040's in a "hypercube" system. Such HyperCubes are at the moment
>being developed at the Norwegian Institute of Technology. An early prototype,
>16 i486 connected together (with local memory and disk), was capable to raytrace 
>a picture much faster than any other HyperCube in the world (i think it was by 
>a factor of 10). It was done in just a couple of seconds. Merging and sorting 
>two files were done 10-100 times the performance of a big mainframe. This system 
>was originally designed to be a fault-tolerant system, with at least two copies 
>of every byte on different disks. What about an Amiga HyperCube with 8 68040 
>processors with XX MB local memory...?  :-) However, AmigaDOS would then have
>to be rewritten quite a lot... Another Amiga model: Amiga NevroNet... :-)

	You first!

							Joe.
						Wondering why he didn't
						redirect this to the
						theory groups...

"I SAID I'd like to BUY you a CHICKEN-LEG!"
Newsgroups: comp.sys.amiga.programmer