Microprogramming can be viewed in many ways. All are different, all are correct. Computer scientists typically see microcode as software with unfortunate complications that would go away if only hardware designers would do a proper job. Electrical engineers, on the other hand, see it as an effective hardware design technique and wish computer science theoreticians with their high-falutin jargon would leave them alone.

Microprogramming textbooks reflect their authors’ orientation. Most, starting with Samir Husson’s classic [1], take the software designer’s view. We learn about the technological and economic reasons for microcode, study some real microprogrammed systems, look at applications such as microprogrammed APL or the emulation of historically significant instruction sets, and investigate the difficulties of compiling horizontal microcode. Lest anyone accuse me of putting down this approach, I hasten to point out that my own set of readings on microprogramming [2] follows it to a T.

Similarly, one can view the architecture of a computer as the abstract specification of a software-visible machine or as the result of a set of hardware design tradeoffs. Most books do the former.

Segee and Field take the electrical engineer’s bottom-up approach. They state (p. 5) that “it is the goal of this text to present the fundamentals of microcoded circuit design.” Microcode, to them, is an eminently practical way to control a state machine. Architecture is what results when the tradeoffs of that machine have been properly made. The reader of this book is supposed to build four such machines, or boards. (Anyone who so much as mentioned a board in most computer science programs, let alone expected students to actually build one, would be summarily executed.) The book starts with a simple state machine and grows, through easily digestible stages, to a stack-oriented bit-slice processor with floating-point firmware. Along the way it covers registers, ALU functions, and memory addressing, the stuff of which computers are made. It includes real timing diagrams: important ones, without adherence to which the boards will not work. This approach is a far cry from the standard timing diagram of, say, an IBM 370/158, introduced in most microprogramming texts for the sake of realism but clearly so tangential to the book that it might as well be captioned “Turn the page--quick!”

The student who goes through this book will really know what designing, building, and microcoding a computer is about. He or she will not know what virtual memory is, what requirements multiprogramming imposes on an architecture, how or why multiprocessors are put together, or what the instruction set of a typical real-world system looks like. Which is more important? I don’t know. The ideal curriculum would include a semester of each.

If your approach leans toward the electrical engineer’s, and if you like the 7400 TTL logic family (which the book uses throughout, augmented by a few more complex parts toward the end), this book is excellent. Its style is a delight to read: neither overly pedantic nor artificially cute. The text is laudably free of typos. The chapter exercises avoid the extremes of “find the answer on page 47 and parrot it” on the one hand and “write a master’s thesis” on the other. The emphasis on design tradeoffs, which begins at the bottom of page 1 and does not let up, is both rare and welcome. My only criticism is that references are minimal, especially on the architecture side, and lean heavily toward integrated circuit data sheets. Of the seven references on RISC (the only high-level architectural topic covered in the book) four are from BYTE and three from the electrical engineering trade press. If you like its orientation, I cannot think of a better text than this for its purpose.