Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!pdn!rnms1!alan
From: alan@rnms1.paradyne.com (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <5967@pdn.paradyne.com>
Date: 21 Apr 89 16:36:19 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP>
Sender: news@pdn.paradyne.com
Reply-To: alan@rnms1.paradyne.com (Alan Lovejoy)
Organization: AT&T Paradyne, Largo, Florida
Lines: 45

In article <423@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes:
>"Compilers can do optimizations", I hear the yelling. This is another
>interesting phenomenon - reduce the complexity in the CPU so that the 
>compiler must do all these other optimizations. I have also now seem any
>indications that a compiler can to anywhere close to an optimal job on
>scheduling code or pipelining. Even discounting the NP-completeness of
>just about everything, theoratical indications point the other way,
>especially when the compiler has to juggle so many conflicting constraints.

If optimization is too difficult for compilers, how in the *&^%$#@! is the
hardware going to be able to do it??????!!!!

The compiler knows a LOT more about the istruction stream--and the intent of
the instruction stream--than the hardware does, with one big exception:  the 
hardware knows the dynamic instruction sequence; the compiler does not.  
Unfortunately, even the hardware doesn't have all that much advance notice of 
dynamically variable parameters.

The reason for increasing the primitiveness (a better characterization than
"reducing the complexity") of machine instructions is so that the compiler
CAN "do all these optimizations," not so that it "must."  RISC does not force
optimization, it permits it.  "Complex" or "high-level" instructions
necessarily become too application-specific.  The greater the semantic content
of an instruction, the less its generality.  The more primitive the instruction
semantics, the greater the probability that the instruction only does what
you need, and not what you don't.  Have you ever tried emulating unsigned
multiplication/division on a system that only provides signed integer
arithmetic and comparisons?  

Because primitive instructions do less work than "complex" instructions,
they can execute in less TIME.  This means either fewer and/or SHORTER
clock cycles.  At first blush, it would seem that complex instructions
can compensate for this by means of parallelism (e.g., pipelining,
mulitiple identical, parallel functional units).  But in practice, there
is no such thing as free lunch.  The steps in the hardware "algorithm"
that implements a complex instruction are usually inherently sequential (fetch
data from memory, do operation, store data to memory).  The parallelizable parts
tend to be the same functions that are parallelizable for primitive 
instructions.  So complex instructions usually gain nothing from this, 
relative to primitive instructions.  
 
Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne.  They do not speak for me. 
_________________________Design Flaws Travel In Herds_________________________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.