From: ted@telematics.com (Ted Goldblatt)
Subject: Re: RISC == direct execution of microcode ?? ( was: Interpreted code)
Organization: Telematics Intl., Inc.; Ft. Lauderdale, FL
Date: Thu, 16 Apr 1992 00:03:47 GMT

In article <1992Apr15.201056.25500@dvorak.amd.com> davec@nucleus.amd.com (Dave Christie) writes:

>
>Given your S38 reference, I'm not sure whether you're referring to the 
>problems with giving users access to the microcode of current or future
>CISC machines, or to perceived problems with RISC philosophies and the 
>best way to develop new architectures.  

Some of each, mostly the former.  However, I do have philosophical problems
with making pipeline and delay timing visable, as it complicates more
advanced implementations, and it isn't necessary, as the current and upcoming
generations of superscalar and speculative execution RISC processors shows.

>
>As for binary compatibility, fear not - it is understood to be important
>enough by anyone who has at least one generation of product out there.
>

However, it appears (from the literature) that the early(est)  proponents 
of RISC (who were in academia, and therefore may not have thought in 
terms of "product") did *not* see binary compatibility as a requirement.
The assumption seemed to be that as improved implementations (better
pipelines, better register organizations, etc.) or even improved architectures
came into being, code would be rebuilt for the newer systems.

>As for dependence on compilers, I think compiler technology has been 
>maturing along with RISC sufficiently to not be a very serious issue.  
>If it is an issue, it's strictly a performance one, not one of depending 
>on timing for functional correctness (binary compatibility again), so 
>maintaining code for a range of compatible machines isn't as much of an 
>issue.  

Admittedly, correct execution is the basic requirement for binary (backwards)
compatibility.  But if a range of binaries are needed to make optimal use of
a range of implementations of an architecture, that may not be much better
from the end user's point of view.  Performance is usually what we are paying
for when we buy the new implementation.


>            The operation timing that does tend to be exposed in RISCs is 
>limited and easily handled (load and branch delay slots) and was done for 
>good performance reasons.  (They they become less valid as more realestate 
>allows fancier internal organization, but at least tend not to hurt).

Unforunately, they are still there, and must be taken into account in future
cvompilers and h/w implementations.  The fact that Alpha doesn't have 
visible delay slots seems to be a *good thing*.

>The i860 is an example of something that goes too far with timing
>visibility, IMHO.

No argument here!

>One last point: you also referred to the parallelism possible with
>horizontal microcode.  At least in the context of conventional CISCs,
>this is mostly a red herring.  The opportunity seems similar to VLIW,
>but there's a critical difference: the primitive operations in a VLIW
>"instruction" are independent of each other, and it takes multiple 
>input operands and produces multiple results.  The operations in a CISC
>instruction tend to be dependent, each one needing the result of the 
>previous as an input; this forces serial execution.  More complex
>instructions operating on multiple operands may have more parallelism 
>available, but the more complex an instruction is, the more special-case 
>it is and the less often it is used, hence speeding it up has little 
>overall effect.

True as far as general purpose architectures and general purpose applications
go.  However, one of the starting points of this thread was with regard to
special purpose applications.  Here (at Telematics) we have built medium
width (60-80 bit) microcoded datacomms engines.  We have reimplemented them
(or at least simulated this :-)) using "general purpose" (commodity) RISC
processors.  While the RISC processors are (in some sense) more powerful,
they can do *less* on each cycle for this specialized application; therefore
they must execute more cycles.  Certainly the RISC processors are available 
at higher speeds, allowing us to offset this penalty, but at the expense of
generally larger, certainly faster program memories, increased EMI concerns
due to the increased clock speeds, increased risk of noise (a major problem
with the presense of large numbers of high speed comms lines), etc.

These processors are special purpose and are not programmed by anyone but
us; that may make them too specialized for this discussion.  However, the
same can be said about many (most?) embedded applications.  This is not
to argue that all such applications have sufficient parallelism to 
benefit from this approach, only to argue that using the general purpose
case at the expense of the special purpose case may be too extreme.

>
>One more last point: major performance improvements rely on exploiting 
>parallelism - the fact that CISC instructions tend to translate into 
>dependent sequences of microinstructions works against this.  A RISC
>compiler can rearrange the primitive operations to maximize the 
>parallelism seen by the hardware; a CISC compiler has at least one hand
>tied behind its back.  The fact that people felt a need to develop
>compilers for microcode says it all.
>

I'm not sure that I buy this argument as an architectural as opposed to
implementation issue.  The fact that clock for clock a 68040 beats the
current generation of SPARC implies that CISC and microcode may be
two entirely separate issues.  Further, dynamic re-ordering and speculative 
execution may provide both CISC and RISC architectures with ways to 
"maximize" available parallelism without making such implementation issues
into architectural ones.  (I won't dispute that there are other 
implementation issues related to CISC vs RISC that may make RISC
architectures easier to scale in performance, though the problems
with the Viking may indicate that SPARC isn't as easily scaled
as Sun had hoped :-)).



-- 
Ted Goldblatt    ted@telematics.com     (305) 351-4367
    Telematics Intl., Inc.   Ft. Lauderdale, FL