Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!cca!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.micro
Subject: Re: Need a microprogramming consultant!
Message-ID: <504@ima.UUCP>
Date: Tue, 5-Mar-85 23:37:39 EST
Article-I.D.: ima.504
Posted: Tue Mar  5 23:37:39 1985
Date-Received: Fri, 8-Mar-85 03:53:44 EST
Lines: 17
Nf-ID: #R:drux3:-127200:ima:11700011:000:993
Nf-From: ima!johnl    Mar  5 21:42:00 1985

I wish we saw more stuff here like the note from ucbtopaz!mwm on 
microprogramming.  Clear and to the point.  But I can't resist a few niggles.  

One thing to keep in mind is that microprogramming is a mixed blessing.  There 
is an increasingly popular school of thought that states that the slowdown 
from interpreting microcode isn't worth it, and you'd be better off making a 
very simple machine that executes instructions directly, and depending on your 
compiler to generate code for it.  The Berkeley RISC is one of the best known 
of the efforts to do this.  Microcoding made more sense when ROMs (where 
microcode usually lives) was much faster than RAMs (where regular programs 
live.) These days, in most systems they're about the same speed, which negates 
much of the speed people used to hope for from microcode.  

Finally, it turns out that microprogramming is far from a new idea.  It was 
originally proposed for an early British machine in 1952!  

John Levine, ima!johnl