From: jjsmith@nyx.cs.du.edu (Jonathan J. Smith)
Subject: Re: cisc -vs- risc
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Distribution: comp
Date: Sat, 10 Oct 92 22:31:20 GMT

In article <35581@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>In article <1992Oct3.1124.12923@channel1> "jeff ruck" <jeff.ruck@channel1.com> writes:
>>-> And you get all the nice instructions as well.  Just about any
>>-> architectural
>>-> tricks they can pull in a risc chip for speed can be done in a cisc
>>-> chip as
>
>>I disagree.  RISC designs, take the R4000SC for example, is designed
>>with a nice secondary cache, I just don't think CISC chip developers can
>>pack the added "features" of third-generation RISC processors on their
>>chips.
>
>There's absolutely no reason you couldn't have a CISC processor with a built-in
>secondary cache manager like the R4000.  It's more a matter of practicality.
>The R4000SC or MP is a 400-something pin chip.  That external SRAM and 128 bit
>bus doesn't come cheaply.  If you don't think anyone would buy your CISC 
>processor in such a configuration, you certainly aren't going to make it.  If
>you're Intel, with its large pretty captive market, you may not even worry about
>it.  After all, you don't need to completely keep up with RISC, you just need
>to keep close enough to prevent a migration.  Part of that necessitates keeping
>your chip costs down and chip profits way up.  Most of the RISCs are attempting
>something close to "balls to the wall" performance, where any trick they can
>manage is worth it to keep ahead of the other guys.
>

Agreed completely, I think perhaps the original author mistook the R4000 sc as
having the scondary cache on chip??.. again most things that can be done
to speed up risc can be applied to cisc, generally though it is easier/simplier/
faster to do with risc designs than with cisc designs.  This doesn't
however preclude one from doing just that.

>>-> well.  The 040 averages an instruction every 1.3 clock cycles, which
>>-> is how they get 19.2 mips out of one at 25Mhz.  A good risc chip today gets
>>-> 1 per clock cycle.  They're not that far behind.
>>
>>I'm not overly familiar with '040 performance, but here are a few facts:
>>Second-generation RISC processors (R3000, etc ...) *completed* one
>>instruction every 1.2-1.6 clock cycles. 
>
>The 68040 is very comparable with R3000-generation RISC processors in terms of
>performance, instruction completion, etc.  Given enough effort, there's no
>problem adapting CISCs for RISC level performance using all the RISC (or
>perhaps supercomputer) tricks.  What's not real apparent is that this tends to
>cost more transistors for CISC than RISC.  Instruction decode is much more
>complex, even for a reasonably orthogonal CISC like the '040.  That's why they
>microcoded or trapped some of the '030+'882 instruction set, you reach a limit
>on what's practical without sacrificing overall performance.  Which is why you
>need to recode optimal performance on an '040 or '486.  
>
>In theory, the CISC instruction stream could be pre-decoded and cached in an
>expanded form, like AT&T's Hobbit (CRISP) does, though far as I know no one's
>really found the need for that yet in a CISC.  This tends to make the cache
>to execution pipeline much simpler, but it requires a larger internal cache.
>
>And CISC could teach RISC a thing or two.  For example, the 680x0 instruction
>set has register increment/decrement for stacks, or register offsets for 
>indexing.  On the '040, these are handled by separate ALUs, so they add no
>extra time to the execution of an instruction.  Most RISC processors would
>require twice the number of cycles to perform the same operation.  And these
>things are actually used by compilers all over the place.
>
>> The latest third-generation RISC processors (R4000SC, Alpha, etc) *issue* as 
>>many as two instructions per clock cycle and *complete* 1.2-1.3 instructions per
>>clock cycle via superpipelining or superscalar designs.  
>
>I think you'll see the next generation of CISCs going to multiple execution
>as well, probably superscalar.  In fact, the Intel folks already claim that
>the P5 does issue two instructions for about 30% of its fetches (of course,
>50% is the maximum possible here).  It wouldn't surprise me if a superscalar
>680x0 could do a bit better.
>
>>-> Er...I thought the fastest RISC chips actually executed *several*
Well stated..

>>-> instructions per cycle?
>
>There's generally different limits on how may instructions can be issued and 
>how many can be executed.  The former is a function of the fetch and decode
>units, the latter a function of the actual execution units.  For example, the
>Motorola 88110 has something like two integer, a floating point add, floating
>point multiply, graphics, and a couple of other execution units, all of which
>can be working together.  The trick is to get code ordered to overlap things
>properly so the non-parallel parts of the pipeline don't stall.
>
>>Simply, superscalar designs initiate pipelines in parallel, and 
>>superpipelining is pipelining several smaller pipelines.  
>
>In the R4000 sense, superpipelining is simply a pipeline that runs at twice
>the clock rate.  The supercomputer folks simply called this pipelining.
>
>>Theorectically, completely 1 insturction per clock cycle is ideal, but very 
>>difficult to implement.
>
>Sure is.  The problem is that most instructions via for the same kind of
>resources.  It gets really expensive to add additional register ports and
>other forms of parallelism, all with the necessary dependency interlocks,
>beyond a certain point.  But they are getting better at it, and they're
>getting a bigger budget (chip expenses are measured in transistors and logic
>complexity, not directly in cash).
>
>-- 
>Dave Haynie Commodore-Amiga (Cool Advanced High-End Systems You Can't See Yet)
> "The Crew That Never Rests"  {uunet|pyramid|rutgers}!cbmvax!daveh   BIX: hazy
>              "I got a pocket full of kryptonite" -Spin Doctors


Jonathan Smith
Newsgroups: comp.sys.amiga.hardware