NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/amiga/programm/17575

Internet Message Format | 1992-12-21 | 6.7 KB

Xref: sparky comp.sys.amiga.programmer:17575 comp.sys.amiga.hardware:21824
Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!netsys!ukma!cs.widener.edu!dsinc!bagate!cbmvax!daveh
From: [e-mail] (Dave Haynie)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re: CISC and RISC
Message-ID: <[e-mail]>
Date: 16 Dec 92 20:52:43 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 106

In article <[e-mail]> [e-mail] (Edsel Adap) writes:
>In article <[e-mail]> [e-mail] (Eric Dewald) writes:
>>Why should computer makers go from CISC to RISC?

>RISC - Reduced Instruction Set Computer
>CISC - Complex Instruction Set Computer

Keep in mind that the term "CISC" was coined by proponents of RISC, in order
to make it sound like there's some sharp dividing line.  There isn't.  The
differences are more related to the particular designs in vogue at the time any
particular microprocessor family was created.

>The reason for many companies going RISC is because of its great speed
>advantages over CISC.  This is accomplished in many ways.  In CISC, (ie a
>Motorolla 68000) the instruction set is what is called a macro instruction.
>These macro instruction are a collection of micro instructions that do what
>the macro instructions is supposed to do.  In RISC instead of a macro
>instruction, there is a minimal amount of instructions, and a minimal amount
>of addressing modes.  More efficiency is obtained by working with the micro
>code because there are things that the macro instructions do in order to
>generalize the instructions for various purposes.  Micro code is to Macro
>code as assembler is to a high level language.  The Micro code provides more
>efficiency.

Some of that's true, but not the way it's written.  The instruction sets
themselves are very similar between any "CISC" and "RISC", though you'll usually
fine more instruction variations in a "CISC" machine.  Micro code, on the other
hand, is all but incomprehensible to most people.  The early versions of most
modern CISCs had their instructions implemented via micro execution units, but
that was nothing more than an implementation detail.  Truely modern CISC CPUs
like the 68040 and 80486 have the bulk of their instructions hard wired, just
like the RISCs.  If you're looking for a real telling difference between the
two, the one give-away is the bitwise encodings of the various instructions.
Most (not all) RISC processors tend to have very straightforward and orthogonal
instructions, all based on a common instruction word size.  This is designed to
simplify the machine's execution pipeline, at some cost in memory efficiency.
CISC processors tend to have more efficient instruction encodings with much
more variation in word lengths, etc., which can force a decoding penalty (in
pipeline complexity if not execution time).

>In RISC chips the data path cycle time is minimized by logically reducing
>the number of steps it takes for an instruction to be executed and by
>physically shortening the distances between components in the chip (the
>large number of registers play a role in this).

For the most part, RISC design efficiencies alone haven't yielded increased
performance, all things being equal.  Of course, things are never quite equal.
The simpler instruction decoding used in modern CPUs has made it easier to
apply new techniques, like multiple execution units or superpipelining (things
generally borrowed from the last generation of super computers).  So you get
these advantages a generation sooner than you would on a CISC processor.  A
simpler instruction decode and execution design takes fewer transistors, so at
the same level of technology, a RISC may be able to support more independent
execution units, larger caches, or more registers for the same chip real estate.

>There is also a significant amount of parallellism and pipelining in RISC
>chips.  As soon as an instruction is started another instruction may be
>started even before the completion of the previous instruction.

This is typical of the latest CISCs too.  The RISCs had it a generation sooner.

>On many RISC chips as many as 4 instructions can be completed in one clock
>cylce as a result of this.

I think the Motorola 88110 could have something like 10 instructions executing
at one time.  However, this processor is on the way out, due only to politics.
Technology doesn't necessarily win on its own.

>CISC I think is easier to program.  RISC is difficult as you have to worry
>about timing your instructions properly.

These days, you, or more properly, your compiler, needs to be clever about
ordering instructions on either RISC or CISC to get the greatest performance.
This was first an issue on the Motorola family back in 1988, when the 68882
math chip was released.  It has a small degree of parallelism if you ordered
its instructions properly.

>If you issued a memory write and do a read from the same location immediately
>after the write instruction, the data you may have wanted to read may not be
>there yet!  So you may have to issue the write a few steps earlier than you
>would normally on a CISC chip.

You have to do that to get the greatest efficiency.  All commercial RISC chips
have instruction interlocks in hardware to resolve such conflicts.  They really
have to, since if they require the compiler to handle such things, it will
invariable have to insert NOPs on occasion that become unnecessary (and waste
time) on the next generation of that CPU.  This is one of the problems the
MIPS architecture had initially -- MIPS stands for "Microprocessor without
Interlocked Pipeline Stages".  Occasionally the compiler had to insert NOPs.
On the R4000, this is resolved in hardware, so new binarys run faster than
old ones, but aren't downward compatible.  With any new processor, there's a
good chance that the instruction orderings or, especially with CISCs, even
the instructions generated themselves change in optimization with new
generations, this is as true going from 68000 to 68040 as with anything.  But
a properly targeted 68040 program with all the reordering you like will still
execute on a 68000.  It's important to consider the future and even the past
when you're building a new processor.



--
Dave Haynie / Commodore Technology, High-End Amiga Systems Design (cool stuff)
 "The Crew That Never Rests"  {uunet|pyramid|rutgers}!cbmvax!daveh   BIX: hazy
        SCIENCE:    "I'll believe it when I see it"
        RELIGION:    "I'll see it when I believe it"