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