From: davec@nucleus.amd.com (Dave Christie)
Newsgroups: comp.arch
Subject: Re: RISC == direct execution of microcode ?? ( was: Interpreted code)
Date: 15 Apr 92 20:10:56 GMT
Reply-To: davec@nucleus.amd.com (Dave Christie)
Organization: Advanced Micro Devices, Austin TX.

In article <1992Apr15.000837.12583@telematics.com> ted@telematics.com (Ted Goldblatt) writes:
>In article <1992Apr14.161134.10190@dvorak.amd.com> davec@nucleus.amd.com (Dave Christie) writes:
>>
>>[microcode] can give you flexibility in meeting various cost/performance goals
>>over a range of implementations - a strategy that was useful in the 
>>mainframe and mini world of years gone by for low- and mid-range 
>>machines, but which I think has little merit in these days of leapfrog
>>high-end microprocessor development.  When you throw more into hardware,
>>I think any gains to be had by tailoring the microcode can be cancelled by
>>the cost of having the microcode (realestate, extra pipe stage).
>
>The only concern I have with this is any dependence that use of the greater
>performance has on use of new compilers or instruction schedulers.  (Or worse,
>the possibility of loss of binary compatibility.)  In many if not most
>environments, loss of binary compatibility can be fatal, either because
>the user is not able to rebuild for the implementation (no source, etc.) or
>because a range of "compatible" machines must be maintained, and the logistics
>of managing incompatible versions of applications are not practical.  The
>microcoded implementation hides the timing and other details much better.
>The IBM S38 approach of hiding the actual machine interface works even
>better, but has other disadvantages.

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.  I agree if it's the former.  If 
not, I can go into a long diatribe, but I'll try and keep it short.

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.

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.  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).
The i860 is an example of something that goes too far with timing
visibility, IMHO.
When compilers lag the capabilities of bleeding-edge machines, as we
have seen with some superscalar designs, I think it's mostly a result
of them not being done in concert with the hardware design.

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.

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.

>>At a more philosophical level, where computing is viewed as a collection
>>of primitive data movement/manipulation and branching operations, Steven's
>>statement is exactly correct.
>
>Unfortunately, it may be too philosophical to be practical.

For developing new general purpose architectures, it is precisely the
point of view one must take, IMHO.

>-- 
>Ted Goldblatt    ted@telematics.com     (305) 351-4367
>    Telematics Intl., Inc.   Ft. Lauderdale, FL
___________________________________________________________________________
Dave Christie	 AMD Advanced Processor Development	 My Opinions Only.
Newsgroups: comp.arch