From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Date: 16 Dec 92 20:01:06 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA


	NOTE: I'll talk in generalities, since most absolute statements about
CISC vs. RISC have at least 1 exception.  This is a topic often debated in
comp.arch; if you want more info go there.

jxp@dcs.ed.ac.uk (Joe Potter) writes:
>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!

	Actually less complex _in implementation_.  Addressing modes are one
of the big complexities of most CISCs.

>>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!

	Many RISCs only support 1 or sometimes 2 addressing modes (The GE
RPM-40 RISC I worked on the design team for had 1 mode: register plus constant
offset - note that since R0 == 0 always, you also have absolute addressing).

	Most RISCs have only one instruction size, instead of N for many
CISCs.

>>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.

	Sorry, you're wrong here.  CISCs have all sorts of "interesting"
optimizations possible (look at all the assembler tricks people are so proud
of that most compilers can't generate).

	In a survey of the improvement available with hand-coding versus using
C, with top-notch ASM programmers, for CISCs the difference was in the 2-2.7
range (in size, not always as much in speed).  For RISCs it ranged from
.95-1.3.  Note: for some RISCs, assembler programmers did _worse_ than the
compilers.  The reason is that with simple instructions, the compiler can spend
more time optimizing expression evaluation, register coloring, etc and less
worrying about chosing between 24 different addressing modes.  Quiz: how
many people can, off the top of their head and _without_ looking, list all
the addressing modes of a 68020?  I know I can't (all the 68000, easy.  Most
of the '020, probably.  All? I doubt it.)  Please don't respond here, but do
think about it.

	I know this first-hand: I was a principal in the back-end software
team for an early RISC (2nd generation), and wrote the code-reorganizer (to
reorder code for faster execution, and insert NOPs where needed to avoid
pipeline clashes).

>>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?

	This allows reordering to get data into registers before it's needed,
so you don't have to wait on _slow_ external memory for the data.

>>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.

	It's bigger because operations are simpler (so it sometimes needs
more instructions to do, but the result can still be faster - hell, on the '020
it's faster to use most of the 68000 addressing modes and avoid many (not all)
of the new modes, since the new modes are slower than the 2 or 3 old
instructions to do the same thing.  ( d8(An,Dn*N) being an exception I think).
Also, the instructions are usually less tightly encoded, for faster decode.
The MIPS R4400 uses 1/2 cycle for decode, for example.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.