Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!ucbvax!ucbtopaz!mwm From: mwm@ucbtopaz.CC.Berkeley.ARPA Newsgroups: net.micro Subject: Re: Need a microprogramming consultant! Message-ID: <784@ucbtopaz.CC.Berkeley.ARPA> Date: Mon, 4-Mar-85 04:44:08 EST Article-I.D.: ucbtopaz.784 Posted: Mon Mar 4 04:44:08 1985 Date-Received: Wed, 6-Mar-85 03:40:50 EST References: <1272@drux3.UUCP> Reply-To: mwm@ucbtopaz.UUCP (Praiser of Bob) Organization: Missionaria Phonibalonica Lines: 82 Summary: In article <1272@drux3.UUCP> mmt@drux3.UUCP (ThomasMM) writes: >I am not a very hardware oriented. Could someone give >me an explanation (in simple terms) of how microprogramming >works????? Reply either via mail to ihnp4!drux3!mmt >or via the net. Thank you. Since someone else asked for the reply to go to the net, I'll give everybody a chance to correct me. First, I'm going to assume that you meant "writing microcode for a processor" rather than "programming a microprocessor" when you said microprogramming. If I'm wrong, stop reading here. Recently (like the last decade or so), people have discovered that building a "two-level" machine buys you various things. The idea is that instead of building hardware that interprets the machine instructions that are your target directly (this is the macromachine), you build hardware that interprets a simpler machines instruction set directly (this is the micromachine), then write an interpreter for the target macromachine that runs on the micromachine. The things this approach buys you include faster development time, cheaper development, easier "hardware" fixes, easier inter-machine compatibility, and probably others I've missed. The cost is that the microcoded processor is slower than a hardwired machine. To help with the loss of speed, most microcoded machines put in a small amount of high-speed memory, and store the microcode in that. This is usually referred to as the "control store" (CS). On some machines, you get a "Writeable Control Store," or WCS. Examples: Almost any modern machine, but I'm going to pick on the IBM 370 line. The entire line was microcoded. Most (all?) of the machine had different hardwired machines underneath them, but the line had identical macro instruction sets. Estimates on how much slower this made user code run go up to 1000% percent, but the low end 370's used standard user memory for control store. There was enough speed loss at the high end that Amdahl did fairly well selling hardwired 370 clones that ran faster and cost less. IBM used the microcode capability to fight this, by releasing OS's that required concurrent microcode changes to add new instructions. Obviously, if you can run your code as microcode, then it will run faster than if you run it as machine code. On a modern machine it will get the benefit of the fast memory, no instruction fetches to the machine memory, and not having to pass through instruction decoding. If you've got a machine with a WCS, you can create your own instruction that do whatever you'd like them to do. This is the kind of thing normal mortals do when they are "microprogramming" a machine. Examples for this kind of thing include putting butterfly FFT's in microcode, obscure table lookups, and block move instructions. Burroughs sells machines which have "what microcode" indicators in the process data structure, and you swap in that process's microcode when you run the process. The BBN C/70 goes even farther, and includes a C compiler for microcode. You tell the linker, and it builds "subroutine linkage" that amounts to a new instruction to call your microcode routine. The difficulty of writing your own microcode depends on the micromachine in question. Micromachines come in two basic flavors: vertical and horizontal. Vertical micromachines look like simple conventional machines. For example, writing for the WCS-11 module on the 11/03 is about like writing for an 8080, except for subroutine linkage. Horizontal micromachines have nice long words (in the hundreds of bits), with bits to open/redirect gates, and other such nitty-gritty. There tends to be obscure timing constraints, and other things you'd rather not have to worry about. You can't get closer to the machine without a soldering iron. Since this lets you use the inherent parallelism in the hardware, it can result in very fast code. It also gives me headaches. As esoterica, it might be noted that some machines have three such levels: a macro machine that the users get to see, a micro machine that microcoders write for, and a nanomachine that truly crazy people write for. The Nanodata QM-1 does this, and I've heard rumors that the 68K chips have three levels. There is an ACM Computing Surveys on microprogramming that includes an excellent introduction to the topic. My copy is buried in one of a large number of boxes. If you'd like the reference, send mail. Or maybe some kind soul will post it.