Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!zs01+
From: zs01+@andrew.cmu.edu (Zalman Stern)
Newsgroups: comp.arch
Subject: Re: 88k needs fewer instructions than VAX. (Was: Compiling - RISC vs. CISC)
Message-ID: <EYjByca00Vs8ILNl8K@andrew.cmu.edu>
Date: 13 Jul 89 18:30:00 GMT
References: <13976@lanl.gov> <199@dg.dg.com> <28471@ames.arc.nasa.gov>,
	<200@dg.dg.com>
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
Lines: 81
In-Reply-To: <200@dg.dg.com>

> Excerpts from ext.nn.comp.arch: 10-Jul-89 Re: Compiling - RISC vs. CISC
> Robert Cousins@dg.dg.com (1876)

	[text deleted]

> At one point, people were talking about RISC processors
> needing to execute MORE instructions to do the same amount of work.
> THis implied that where a CISC might require 100 instructions, a
> RISC might require >100 instructions, though the RISC instructions
> would take less time.  We have noticed that in many cases, the 
> instruction count goes down.  In fact, the best example is the
> Dhrystone benchmark.  Since Dhrystone is an artificial measure of
> integer compute power, a "Dhrystone MIPS" is considered one VAX MIPS
> of compute power.  On the 88K, we need less than 1 MIPS to generate
> a Dhrystone MIPS.  In other words, we get Dhrystone MIPS > CPU
> clock speed.  When this first happened here, many people were
> mumbling about clocks running backward and Escher paintings . . . . :-)

> Excerpts from ext.nn.comp.arch: 13-Jul-89 Re: Compiling - RISC vs. CISC
> Robert Cousins@dg.dg.com (1858)

> Hugh, I agree that Dhrystone is one benchmark in a whole field of
> benchmarks.  However, I feel comfortable drawing a simple conclusion
> from this result:  It is not clear that a CISC processor will take
> FEWER INSTRUCTIONS to solve a problem than a RISC processor.  In some
> cases RISCs may require fewer instructions.

	[text deleted]

> Robert Cousins
> Dept. Mgr, Workstation Dev't.
> Data General Corp.

The situation given in the first excerpt is in no way supporting data
for the conclusion made in the second excerpt. In order for the first to
be at all surprising, one must assume that "Dhrystone MIPS" are related
to native instruction issue rate. This is not true.

To make the discussion clearer, I will introduce some notation:

    DPS(machine) = Dhrystones Per Second for machine.
    NIIR(machine) = Native Instruction Issue Rate of machine,
    VUP(machine) = VAX Unit of Performance measure for machine. (For the
sake of
        this argument, a VAX 11/780 is one VUP.)

I use VUP here because MIPS is often confused with native instruction
issue rate. This is very seldom what is meant by MIPS. Therefore, I will
avoid the term MIPS entirely. An 11/780 gets something like 1700
Dhrystones. Hence there are about 1700 Dhrystones to the VUP. As far as
I can tell, Robert Cousins statement was that he was surprised by the
fact that for their 88k machine, the following was true:

    (DPS(88k) / 1700) > NIIR(88k)

I take it that Robert was surprised by this because he supposed:

    *) (DPS(VAX 11/780) / 1700) = NIIR(11/780)

Substituting the values of DPS(88k) that he was getting, NIIR(88k)
turned out greater than the clockspeed of the 88k machine. His
conclusion was that the 88k was executing less instructions than the
VAX. It has been covered before in comp.arch that a VAX 11/780 really
has a native instruction issue rate of somewhere in the neighborhood of
500k instructions per second. This makes the *'ed equation untrue. This
is the fallacy in the above conclusion. In fact, making any native
instruction issue rate conclusions based on Dhrystones is a bad idea
since it is doubtful that the two machines are executing anything close
to the same code.

Another problem here is that the term RISC is as bogus as the above
usage of the MIPS abbreviation. The 88k differs from other processors
described as RISC in that it has addressing modes for its load and store
instructions. There are probably interesting discussion to be had as to
code density and architectural features (i.e. address modes), but I
don't have any data so I'll shut up.

Sincerely,
Zalman Stern
Internet: zs01+@andrew.cmu.edu     Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890