mmt@drux3.UUCP (ThomasMM) (03/01/85)
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.
ped@ahuta.UUCP (p.davidson) (03/01/85)
REFERENCES: <1272@drux3.UUCP> It would be great to see the answer in the net.
mwm@ucbtopaz.CC.Berkeley.ARPA (03/04/85)
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. <mike
droms@PURDUE.ARPA (Ralph E Droms) (03/04/85)
A microprogrammable CPU is one in which control points within the CPU are directly controlled by bits in the instruction word. For example, in a simple machine with two registers (e.g., A and B) connected by a bus, there would be a control bit (e.g., bit 3) in the instruction to gate register A onto the bus, another (bit 2) to gate register B onto the bus, a third (bit 1) to load register A from the bus and a fourth (bit 0)to load register B from the bus. So, to load register A from register B, the instruction would be 0110. Now, extend this to cover ALL the control points in a CPU - and give each one a separate bit in each instruction, and you have a horizontally microprogrammed CPU. But, the information in the instructions will be very sparse (i.e., there will be only a few control points turned on in each instruction). So, encode all the control points in binary and allow only one control point per instruction, and you have a vertically microprogrammed CPU. In practice, groups of mutually exclusive control points (in the above example, you really only want to gate either A or B onto the bus, but not both), are encoded in fields in the microinstruction, resulting in an architecture somewhere between vertical and horizontal microcode. How is microprogramming used? Microprogram storage is typically (although not always) fast and small. The usual practice is to code an emulator in microcode which executes a more "normal" instruction set. This instruction set may be patterned after an existing machine (allowing capture of existing software) or after a more "ideal" hypothetical machine (e.g. a pure stack-oriented architecture). For more detailed descriptions, see: Katzan, Harry. "Microprogramming Primer". McGraw-Hill Computer Science Series (1977). Mano, M. Morris. "Computer System Architecture" (ch. 7-9). Prentice-Hall, Inc. (1976). - Ralph Ralph Droms ihnp4!purdue!droms 445 MATH droms@purdue.arpa Dept. of Computer Science droms@purdue.csnet Purdue University West Lafayette, IN 47906 ----------
hes@ecsvax.UUCP (Henry Schaffer) (03/05/85)
A reference which goes into much more detail is "An Intro to Microcomputers by Adam Osborne, Vol.1 Basic Concepts". It has much of a chapter on microprogramming with very easy to follow examples, and you don't have to know engineering to follow it. --henry schaffer
rpw3@redwood.UUCP (Rob Warnock) (03/05/85)
+--------------- | REFERENCES: <1272@drux3.UUCP> | It would be great to see the answer in the net. +--------------- O.k., this is what I mailed to original poster (edited slightly): ========================================================================== In-reply-to: your article <1272@drux3.UUCP> +--------------- | 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. +--------------- Well, for starters, you haven't said enough for me to know what your problem is. I assume you are talking about microprogramming as used in the design of the instruction set of a computer, or in the design of the data paths of some peripheral controller. Most commonly, "microprogramming" is a term used to describe the design of a hardware finite-state machine which was constructed with it's state-transition matrix in a ROM. (Are you familiar with "finite state machines"?) The contents of the ROM are the "micro-program". Generally, there are a certain number of input variables (logic levels) that can be tested, and which can cause state changes (micro-code "branches"), and a certain number of output variables (logic levels) which can be set, depending on the current state. Inputs might be levels such as "The ALU Output Value Is Positive", or "DMA Bus Request 4", or "Memory Data Bus Bit 15". Outputs might be such as "Clear Timing Flip-Flop 27", or "Enable The Contents Of Memory Address Register Onto The Memory Address Bus". (Hardware engineers often shorten names like the latter to cryptic forms like "MAR2MAEN"... or worse. ;-} ) In the most general case, the input vector is concatenated with the state vector, and used to look up in the ROM the pair "new-state-vector" and "new-output-vector". The "new-state-vector" is saved as the (now current) state vector, and the "new-output-vector" is sent to the various outputs. (Is this all too abstract for you?) "Micro-programming" is the process of selecting those ROM contents, and bears a faint resemblance to ordinary (macro-) programming. Large state machines are easier (thus cheaper) to design using micro- programming than are state machines built of random (or discrete) logic gates, but because of its complexity, it still is expensive to design a microprogram. (The logical conclusion is: "Large state machines are expensive".) The resulting "micro-programmed machines" are also usually cheaper to manufacture than discrete machines, though sometimes they suffer in operating speed. There are many simplifications, complications, and variations to the general case to save space in ROM, to save other hardware, and to simplify design ("programming"). Sometimes there is an explicit "micro-PC" (uPC) which stores the current state vector; sometimes the state vector is implicit in the value of some output variable(s). Sometimes the uPC can be incremented and the incremented value used as the "next state" unless explicitly overridden (allowing next-state bits in the ROM to be used for other purposes except when explicitly needed); sometimes each micro- instruction (word in the ROM) carries with it the next PC (ROM address). Sometimes some of the outputs (from a previous state) are used to select a subset of the inputs to be looked at (this reduces the size of the ROM, since not all possible combinations of "state|input" are needed). Sometimes only certain bits of the uPC are affected ("loaded", or "jammed") by the results of a test. Some micro-ROMs have one bit for every possible output wire or control lead needed; such machines are said to use "horizontal microcoding". Sometimes there is a coded field in the uROM which is decoded externally to select which ONE of several outputs will be activated; such machines are "vertically microcoded". Vertically-coded machines may also take several steps in succession to do what a "horizontal" machine could do in one step; conversely, vertically machines are usually cheaper, because they use less ROM, and fast uROM is expensive. The range of variations is immense. So... there is not very much one can say further without relating it to a specific situation or hardware design problem. Oops! There IS one other little thing: Sometimes when microprogramming is used to design a system (such as a large computer), the designers choose to store the microcode in RAM, rather than ROM. (Obviously, it has to be loaded into RAM from "somewhere" when the machine is first powered up. Usually "somewhere" is a smaller computer which has ITS microcode in ROM, and which reads the large machine's microcode from a disk file.) This means that the low-level function of the machine can be changed if needed (say, to fix a design error or defect) without being re-wired or without replacing (expensive) ROM chips. This has allowed hardware engineers to get nearly as sloppy as software people, so that one now routinely hears "Well, that bug is fixed in the next release of the microcode". ;-} ;-} Note: Several semiconductor manufacturers make special chips that help one to design/build microprogrammed logic systems. The "2900" series chips (made first by AMD but now multiply-sourced) are quite popular for microprogrammed machines. The applications notes for the 2911 sequencer (a uPC with extra goodies in it) will give more examples of how microprogramming is used. I believe there is an AMD app note that even gives a complete diagram for a disk controller, including the table of micro-ROM contents. Ask your local hardware wizard. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
kushnier@nadc.ARPA (03/05/85)
GIGO
As I understand it, Micro-programming is the series of operations that occur
within the microprocessor for placing data and address information on busses,
or routing data to the Arithmetic logic unit; again within the micro itself.
For many processors, this micro-code is burned in and unchangeable. But for
some, the processor looks outside the chip for it's micro-code.
Micro-programming provides a plethora of architectural techniques such as
Pipelining which speed up throughput.
Hope that helps a little.
Ron Kushnier
kushnier@nadc.arpajohnl@ima.UUCP (03/06/85)
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
andrew@stc-b.gb.UUCP (Andrew Macpherson) (03/06/85)
The best explanation in non-technical terms of microcode that I have
ever read was in Tracy Kidder's book "The Soul of a New Machine" qv.
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Regards
Andrew Macpherson
<andrew@stc-a.gb.uucp>
{creed, idec, root44, stc-[b-f], stl, ukc}!stc-a!andrewdarrelj@sdcrdcf.UUCP (Darrel VanBuer) (03/06/85)
Another reason to have microprograms in RAM (besides reducing cost of bug
fixes) used by a number of companies (notably those making Lisp machines) is
tailoring the instruction set of the machine to the application E.g. the
Xerox Dolphin can be an Alto, a Lisp machine, a Smalltalk machine or a Mesa
machine, depending on which microcode is (dynamically) loaded. The Alto
code is straight emulation to exploit a preexisting operating system, the
others implement an abstract machine model tailored to the language.
The Dolphin has only a single processor, but has a small read-only
microprogram memory which contains just enough to bootstrap microcode from
the disk or Ethernet.
Some computers and vendors provide tools for user microcode (usually for
augmenting the instruction set rather than replacing it), a few even
implement virtual memory microstores!
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPApvk@ixn5f.UUCP (Patrick Kauffold) (03/07/85)
Got a couple of free months?
mwm@ucbtopaz.CC.Berkeley.ARPA (03/08/85)
In article <504@ima.UUCP> johnl@ima.UUCP writes: >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. Thank you. >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. Note that (some of) the people selling RISC machines (pyramid) are *still* using microcoded machines. The simpler target instruction set means you need less rom for microcode, and less "magic" hardware - a compromise between pure RISC and CISC (complex ...). In exchange for the interpretation time, you get more flexibility in the machine with less trouble. For instance, pyramid changed from word-aligned word fetches to unaligned word fetches by tweaking the microcode. Like any complex decision, you have to make some trade-offs. >Finally, it turns out that microprogramming is far from a new idea. It was >originally proposed for an early British machine in 1952! Not surpising. Most of the good "new" ideas in CS are rather old. Could you supply a reference so I can read about it? BTW, redwood!rpw3 posted a very detailed description of one form of vertical microcode; as it appears in I/O devices, etc. He also mentions bit-sliced machines (the AMD 2900), which make for fast design of fast custom hardware (like Wirth's Lilith). The reference for such is "Bit-slice Microprocessor Design" by Mick and Brick (no, I'm not kidding), from McGraw-Hill. <mike
henry@utzoo.UUCP (Henry Spencer) (03/08/85)
> Finally, it turns out that microprogramming is far from a new idea. It was > originally proposed for an early British machine in 1952! Actually, the concept of microprogramming goes back much further than that, although it was forgotten for a long time and then re-invented by Maurice Wilkes in 1952. Some of Charles Babbage's drawings for his never-built Analytical Engine show what is clearly, in modern terminology, microprogrammed control for a specialized execution unit. But Babbage never published much about the general principles of his designs, and nobody noticed this particular invention until quite recently. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
rpw3@redwood.UUCP (Rob Warnock) (03/11/85)
+--------------- | >Finally, it turns out that microprogramming is far from a new idea. It was | >originally proposed for an early British machine in 1952! | Not surpising. Most of the good "new" ideas in CS are rather old. Could you | supply a reference so I can read about it? +--------------- Try 1951. The paper (actually, speech) which is generally agreed to have started it all is: Wilkes, Maurice V., "The best way to design an automatic calculation machine", Manchester University Computer Inaugural Conference, (July 1951), pp. 16-18 All you want to know about early microprogramming (and more than you will EVER want to know about microprogramming in the IBM System/360 Model 40, the IBM 360/50, the RCA Spectra 70/45, and the Honeywell H4200) can be found in the text "Microprogramming: Principles and Practices" by Samir S. Husson (Prentice-Hall 1970) [which is where I found the above reference]. In a historical aside, Husson notes [p.25]: "It is believed that Wilkes introduced the term 'microprogramming' with its present meaning. However, the Lincoln Laboratory [at MIT] used it prior to 1950 to describe a system in which the individual bits in an instruction directly control gates in the processor." Those who remember the DEC PDP-8 (which owes much to the LINC processor) will recall this earlier meaning as applies to the PDP-8's OPR instructions and the IOT instruction. (You can build up a complex instruction by taking a basic instruction class and turning on or off individual action bits.) +--------------- | BTW, redwood!rpw3 posted a very detailed description of one form of | vertical microcode; as it appears in I/O devices, etc. He also mentions | bit-sliced machines (the AMD 2900), which make for fast design of fast | custom hardware... | <mike +--------------- Most of my article applies to horizontal machines also (one salient difference being that horizontal machines generally lack an incrementor on the micro-PC, since each "next-uPC" is supplied explicitly). Note that the 2900 series can be used equally well in horizontal or vertical architectures. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404