From: sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
Subject: Re: RISC == direct execution of microcode ?? ( was: Interpreted code)
Followup-To: comp.arch
Summary: RISC == Vertical Microcode / VLIW == Horizontal microcode
Keywords: RISC, VLIW, microcode, history
Organization: University of Virginia
Distribution: na
Date: Wed, 15 Apr 1992 17:58:59 GMT


[ Note: My news server did not get Dennis O'Connor's message, so I can't
  reply to his comments. Dennis : can you email me a copy? ]


I wrote:
  
   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.


In article <1992Apr15.000837.12583@telematics.com> 
	ted@telematics.com (Ted Goldblatt) writes:

>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.
>
> ...
>
>Or looked at another way, simple (multi-cycle) hardware and complex 
>(parallel) hardware.
>

OK. I'll amend that statement: 
  RISC is "user-level" VERTICAL microcode.
  VLIW is "user-level" HORIZONTAL microcode.


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


Yes. micro-coded virtual machines are a useful technique. 
So are macro-coded virtual machines. 
If we had a "standard" interpreted-language/i-code/virtual-machine we 
could have REALLY portable software. It would be neat for distributed
processing. You could always re-compile native mode for faster execution,
but it would be convenient, and convenience is often what the user is 
going to spend his MIPS on. ( Sometime convenience translates to RAW SPEED -
"I want my screen re-drawn NOW" , but not always. We should start thinking
about how we are going to spend the hundreds of MIPS on our desktops wisely.)

I think concerns about backward compatibility, while important, are wandering
a bit off the (original) thread of "specialized architectures". 
But again: ALPHA's approach to emulation LOOKS like a good idea. I'll be very
 interested to see if it is as good as it looks!


[ It's actually splintered into several threads about Lisp-machines, 
  tagged-architectures, micro-code & WCS etc., but I think the common origin
  was how to better support languages other than C and Fortran ( what 
  almost all of the benchmarks and most of the instruction traces used
  to design RISC instructions use. ) better. My point is: microcoded 
  processors is NOT IT. Better ( more appropriate ) RISC architectures 
  for interactive/interpreted/dynamic languages MAY BE it. ] 

>In article <1992Apr14.161134.10190@dvorak.amd.comted| davec@nucleus.amd.com 
>  (Dave Christie) writes:  
>>
>>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.
>-- 

I'm not arguing philosophically, but historically and economically practical.

Historically:
 Some of the ideas behind RISC architecture came from people ( Patterson, 
 et.al. ) who started out trying to make better micro-code tools and 
 architectures. Once you have a good micro-code compiler that handles 
 all the hairy timing problems usually involved in micro-code ( as opposed
 to typical macro-code ), WHY have the macro-code step at all. Especially
 if the next step in micro-code oriented HARDWARE is a cache-like Virtual
 Writable Control Store, so you don't have to manually try to cram your
 microcode into a small memory. 

Economically:
 There are advantages to General Purpose Architectures.
 You may be able to design special purpose hardware that beats the general
 purpose design, but will you have the volume and sales to generate the 
 R&D to build the next generation at a competitive price/performance. 

 I don't think there is enough volume in Lisp-Machines or Smalltalk machines
 to support that type of investment. 


- Steve Majewski