From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: cisc -vs- risc
Date: 5 Oct 92 19:06:55 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Distribution: comp
Organization: Commodore, West Chester, PA

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.

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