One of the deeper dives into RISC vs CISC I've seen

[Chuck Guzis]

On 6/15/19 3:40 PM, ben via cctalk wrote:
> On 6/15/2019 8:47 AM, Stefan Skoglund via cctalk wrote:
> 
>> With VAX 11/780 and S/360 involved ? I don't think so soo
>> the Cyber series and 709(4) could be interesting.
> 
> Well the early 1960's was the rise of BIG IRON that had REAL POWER
> and that led to people thinking about high level languages and Computer
> Science in general. We got  PL/I (USA) and ALGOL (Every where ELSE)
> that is a realy hard to compile into effective code. CISC design is
> now needed to handle the 'extended features'. C was simmpler,
> but still hand many features. RISC came along only because Compilers
> could only generate SIMPLE instructions, that matched the RISC format.

I'm not completely sure I'd agree with that assessment.  Heck, we talked
to the hardware design people to add/modify CISC instructions to fit the
compiler needs.

RISC had a benefit not so much for compiler work, but that a greater
issue rate with the optimization and scheduling tasks left to the
compiler (or programmer) rather than the hardware.

I'll posit that RISC offers little gain on simple unified ALU CPUs or a
CPU with a small register file.  Where are are pipelined, segmented and
multiple functional units, RISC starts to shine, provided that the
register file is large enough and the instruction issue rate is fast enough.

For what it's worth, the number of instructions in the ISA does not
define RISC, but rather that the instructions execute quickly.  Some
RISC implementations have large instruction sets.

In fact, RISC does carry a penalty in that you're executing more
instructions to get something done, so your code space is larger; but,
you hopefully have them scheduled such that the whole task runs faster.

A related subject of "let the compiler do it" is VLIW.

--Chuck