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

In article <1992Apr14.161134.10190@dvorak.amd.com> davec@nucleus.amd.com (Dave Christie) writes:
>In article <DOCONNOR.92Apr13220728@layton.inews.intel.com> doconnor@layton.inews.intel.com (Dennis O'Connor) writes:
>>
>>sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski) writes:
>>]
>>]  The RISC philosophy has often been characterized as "User level micro-code"
>>]  -  rather than building complex instructions from simple micro-code
>>]  instructions, make the basic user-level instructions as fast as micro-code. 
>>]  RISC *is* microcode that uses a cache of main memory instead of a limited
>>]  size writable control store.

Ignoring the significantly greater parallelism that horizontal microcode can
provide over anything less than a heavily superscalar RISC, with dependence
on great compilers and (probably) speculative execution.  Of course, it is
likely that much of the additional parallelism is only rarely used in the
general case; special purpose processors, I/O controllers, etc. may be
more likely recipients of the benefit.

>>
>>I have some difficulty with this statement. The difference between a 
>>RISC Instruction Set Architecture (ISA) instruction and microcode is 
>>related to the difference between a computer architecture and an 
>>implementation of that architecture.
>
>Yes, microcode, unlike RISC instructions, can be tailored to a
>particular implementation - it basically allows one to vary the degree 
>to which an ISA is implemented in hardware vs. software (software 
>being the microcode).

Or looked at another way, simple (multi-cycle) hardware and complex 
(parallel) hardware.

>
>This 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.

>
>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.


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