Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: More RISC vs. CISC wars
Message-ID: <13987@lanl.gov>
Date: 13 Jul 89 22:06:52 GMT
References: <42688@bbn.COM>
Organization: Los Alamos National Laboratory
Lines: 45

> The discussion continues between slackey@bbn.com (Stan Lackey) and me.
> If you are bored with it, "Type 'n' now"
> 
>>[...]                                                            What
>>is the minimum number of clocks between issuing the given instruction
>>and issuing the next instruction which uses one of the results of the
>>one given?  Bet it ain't 1.
> 
> Bet it is, for lots of cases.

Obviously, it _never_ is.  I want the time from instruction issue
to writing of results.  Even by _your_ calculation, this is _always_
six clocks (for the instruction at issue).

> The CE has a fixed six-stage pipeline.  The stages are:
> [...]
> 6. Floating point execution and writing of results
> 
> So, the full execution time of a FP instruction is 6*170.  A new 
> instruction can be started every 170.  

This is just like any other pipelined machine (CRAY, for example).
I would _never_ claim that the divide approximate on the Cray was
one clock (even though that's its issue time).  The instruction
time is number of clocks from issue to completion - nothing else.
When someone says a machine is pipelined, I _assume_ that issue
time is shorter than the whole instruction time (for most instructions).

> Dependencies cause dead cycles to be inserted.  [...]

Finally, this discussion gets back to _my_ point about compiler
construction.  CISC machines usually have a superset of the instructions
found in a RISC machine.  The compiler must determine whether to
use the simpler instructions (in which case, you pay more for instruction
issue - but might find a improved scheduling) or whether to use the
complex instruction (which pays less for instruction issue, but might
cause more delays to be generated).  RISC doesn't have the choice,
so it's _OBVIOUSLY_ easier to compile for!

This still leaves the question of whether RISC or CISC is faster.
This question is independent of the compiler discussion I am talking
about.  My bet would be that RISC could be made faster if the compiler
for the CISC is assumed _not_ to do the optimizations I am talking about.
For this reason I claim that CISC compilers _are_ more complex than
RISC compilers (at least if they generate competitive code).