Xref: utzoo comp.sys.next:15190 comp.arch:21819
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!darkstar!kithrup!sef
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.sys.next,comp.arch
Subject: Re: Low End NeXTs (was Re: Desktop publishing)
Message-ID: <1991Apr03.232400.1560@kithrup.COM>
Date: 3 Apr 91 23:24:00 GMT
References: <4753@lectroid.sw.stratus.com> <34936@athertn.Atherton.COM> <27fa3350.6bc2@petunia.CalPoly.EDU>
Followup-To: comp.arch
Organization: Kithrup Enterprises, Ltd.
Lines: 106

I would suggest that this thread continue in comp.arch, which is more suited
to it.

In article <27fa3350.6bc2@petunia.CalPoly.EDU> araftis@polyslo.CalPoly.EDU (Alex Raftis) writes:
>What makes you say this. Sure RISC is nice, and it has it's place, but 
>look at what advantages RISC gives. It has few intructions, so they execute
>quickly. That's nice, but each instruction does very little, so you need
>five instructions to do the same thigns a CISC processor can do. 

Which end up not being used.

Fact:  the current generation RISCs are almost invariably "faster" than the
current generation CISCs.  Consider 68030 vs. R3000 (I believe those were
about comparable).  Consider 68040 vs. R6000.  In both cases, the MIPS chip
is "faster" (the SPECmarks are higher, by a considerable margin).

Few compilers use any of the nifty instructions that a CISC has.  gcc, for
example, uses a relatively mundane set of instructions for the 68k line.
Most instructions get unused this way, in a CISC; on the other hand, most of
the instructions that the MIPS series has *are* used by the compiler (the
exceptions being about a dozen or so that are used to do things like page
control, processor control/setup, etc.).

>A RISC
>processor has a lot a registers to work with for speed. Well, the 68040
>has sixteen registers, which I find more than plenty when programming.

Maybe you don't, but I can come up with cases where it isn't.  Using the
MIPS again.  It has 32 integer registers (one of which is hardwired to 0, I
believe).  Some of the registers are, by convention, used to pass in
subroutine arguments.  Result?  Subroutine calls are *fast*.  Also, the
return address goes into r31, not onto a stack; this is also quite faster
than the 68040 (MIPS does:  r31 := pc+1; pc = addr, while the 68k has to do
quite a bit more, including storing into memory, decrementing the sp, and
*then* incrmeneting the pc, as well as parsing the addressing mode).

>What are some of its disadvantages? Well, floating point work generally
>is more difficult. They're also nearly impossible to work with at the assembly
>level due to the amount of work the programmer has to do to make the 
>advantages of RISC, like pipelining work.

So?  How often do you program at the assembly level for unix?  I rarely do;
when I do, I use gcc to help.  The MIPS assembler takes care of pipeline
slots, so you don't have to deal with *that* part of it.  In addition, you
*do* realize that the R6000 has essentially the same FP instructions that
the 68040 does?  Yeah, that's right.  The 68040 got rid of *tons* of
instructions.  There goes *that* part of your "CISC is better than RISC"
argument.

>On the other hand, look at the 68040. It executes instructions at around
>1.3 cycles per instuction. 

That depends on your instruction stream.  The R3000 gets about the same
ratio, although I seem to recall "1.2"; however, I don't have any reference
to that, so that's just hearsay.

>It gives you lots of registers. 

So does the R3000.

>It's easy to
>work with at the assembly level while its easy to write compilers for. 

Actually, I have no trouble writing in assembly for any of the current RISC
chips.  And the R3000 is easier to write a compiler for than the 68k;
there's a lot of stuff you don't have to worry about.  (For example, all the
addressing modes.  Sure, they make your code smaller, but not necessarily
faster.)

>It's only major problem is
>in clock speed. A 25 Mhz 68040 can beat a SPARC at 25Mhz, but the SPAC's
>top speed is 40Mhz, which will easily beat the 040. Motorola claims to be
>working on a 50Mhz version of the 040, but I don't have any idea of when
>they claim this will be released.

I don't like the SPARC.  It's got an ugly instruction set.  How about the
RIOS or the MIPS?  They are acknowledged to be the fastest chips, generally
(although the new HP chip[set?] also seems to be pretty fast, as well).

>With their current strategy
>they can work their way into the workstation market with their 25 Mhz
>cube, which requires low cost memory and support hardware, while they wait
>for faster versions of the processor to come onto the market. 

When a 50MHz 68040 comes out, I expect MIPS to come out with a 75MHz (or
faster) R4000; this will be able to get 150MIPS max, and should average
around 100MIPS.  I know that doesn't mean much; let's just say it will have
such impressive SPECmarks (assuming the system is designed to keep pace)
that Motorola would have to come out with a 120MHz 68040 to keep pace.

>Once this
>occurs, they can begin to release faster version of the Cube, while still
>selling their current models as the Workstation for the rest of us.

You can only make things go so fast at any given technology.  Using the
technology to put all of those transistors on a 68040, the RISC people will
make a much faster chip (see R6000, RIOS, R4000 when it comes out).

Go read _Computer Architecture:  A Quantitive Approach_, by Hennessey and
Patterson.  Then make your arguments again.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.