26. Case Study: Book Design of Computer Architecture: Concepts and Evolution

Dust jacket of Blaauw and Brooks [1997], Computer Architecture

Oh that my words were now written; oh that they were printed in a book!

JOB 19:23

Book writing has logarithmic convergence.

Highlights and Peculiarities

Bold Decision

Stick with a narrow but quite precise definition of computer architecture as the scope of the work. Although we first introduced the term in 1962, and a quite precise definition in 1964, it had come to be broadly used in a much looser sense. We carefully define and distinguish architecture, implementation, and realization. We treat only architecture, defined as exactly those properties of the computer that govern what programs will run and what results they will produce, and not how fast. This precision enables one to define program compatibility.

Bold Decision

Incorporate a “zoo” of 30 computer architectures, described in a standardized format. The format includes a prose description of “highlights and peculiarities,” a short description of the historical and technical context, a drawn programming model, enumeration of the design decisions, and precise drawn and APL descriptions of the data representations, formats, and significant operations.

Bold Decision

Build, test, and publish executable simulators of the zoo computer architectures, all written in APL. Each zoo machine includes an executable APL program simulating the machine’s instruction fetch, decode, and calling of the appropriate data-fetching and operation routines. The significant operations are also described with executable APL functions. Building these simulators forced our close scrutiny of the machines and that added great precision to these descriptions. It is not evident that many people have ever used the simulators.

Matrix Organization

The design decisions constituting a computer architecture are treated twice, once systematically in order of the decision domains, and then again in the context of all the interrelated decisions in each specific machine.

Decision Trees

We use decision trees as a formal tool for representing design choices. The 80-some trees are linked together into a single vast unified decision tree for computer architecture. This formalism, of course, treats design as problem solving by search of a well-defined space, which model I argue vigorously against in this book! My view of design has broadened and deepened since we did that book.

Computer Architecture Evolution: Divergence and Convergence

We cover the evolution of computer architecture from the very beginning (Babbage) up through 1985, showing the wide experimental divergence and the subsequent convergence to a surprisingly standard architecture. This brings together documentation of many early computers, as well as modern ones.

Research Monograph as Well

Our work on System/360 and on the book itself yielded many research results that were not piecemeal publishable. Hence the book contains many newly published results, enumerated in its Preface. This is peculiar for what looks like merely a text for practitioners and students.

Comprehensive Reference

Terms are carefully defined. An extensive subject index leads especially to those definitions and their substantial treatments, as well as all occurrences. There are separate person-name and machine-name indexes. The bibliography contains over 500 items. The book may be useful as a reference long after the didactic material is useful for teaching.

Introduction and Context

Authors:

Gerrit A. Blaauw and Frederick Brooks

Dates:

~1971–1997

Context

Both of us had left the practice of computer architecture and were teaching courses in the subject. The book grew as we needed course material. After about two course administrations apiece, we undertook to design a book, not principally as a text for students, but as a systematic treatment for practitioners. We did include extensive exercises, designed for both class use and self-study.

Objectives

From the Preface to Computer Architecture:

“Our aim in this book is to give a thorough treatment of the art of computer architecture. This work is not intended primarily as a textbook, but rather as a guide and reference for the practicing architect and as a research monograph setting forth a new conceptual framework for computer architecture. We have given enough of the historical evolution that one can see not only what present practice is, but how it came to be so, as well as what has been already tried and discarded. Our goal is to display unfamiliar design alternatives, and to analyze and systematize familiar ones.

“It seems useful to provide a compendium of the issues arising in the design of computer architecture, and to discuss the factors pro and con on the various known solutions to design problems. Each architect will then be able to provide his own set of weightings to these factors as dictated by his application, his technology, and his taste and ingenuity.”

Opportunities

Because we had worked closely together for eight years at IBM, communication was easy and thought patterns familiar. This made our telecollaboration easy, as described in Chapter 7.

We had worked together on the design of three computer architectures, and each of us had participated in the design of others. These projects had occasioned our studying the designs of our predecessors, and teaching had solidified our understanding of those works and their significance. We owned programming manuals for most of those machines.

The design of System/360 architecture was not hurried, because its semi-integrated circuit technology would not be ready before 1964. Hence those design decisions were thoroughly debated, and we had studied the pros and cons of many architecture issues in that context.

Book preparation time and effort budget were essentially unlimited. Or so we thought. This was a major mistake. In the event, the book was too late to be of maximum influence and use.

Constraints

Each of us had active research programs and teaching schedules, as well as growing children. After starting this book, each of us published a related book. So this book often languished.

Design Decisions

Sequence

In any expository writing, sequence is the hardest single design decision. The general graph of interrelated concepts must be cut to a tree structure, so it can be mapped onto the linear structure of the text.

We saw two major possible orders, each very important. So we incorporated both orders, with much cross-referencing. Part I treats design decisions systematically in conceptual order. But each real decision must be made in the context of all the other decisions for that computer. So we illustrate the design decisions in the contexts of the several computer specimens in Part II, “A computer zoo.”

The “Highlights and peculiarities” section above enumerates other major design decisions that need no further elaboration.

Assessment

Firmness

As measured by permanence, the design is firm. After 13 years, its usefulness is not diminished nor its treatments obsoleted, although it must be supplemented by material describing more recent developments.

Usefulness

The book came out too late for some of its potential uses. For a textbook for one or two architecture courses, one would use Hennessy and Patterson’s superb and continually updated Computer Architecture: A Quantitative Approach instead.

The professional computer architect needs to be familiar with our work, both for familiarity with his predecessors’ works and as a guide and reference. It has a small but devoted following, mostly among computer architects.

Delight

Others must assess that.

Lessons Learned

1. Probably a less ambitious work sooner would have been more useful to the profession. When I now teach a single course from Computer Architecture, I feature the zoo and its specimens, treating design decisions as they are encountered in vivid examples, rather than systematically. Perhaps we should have written and published that part of the book separately, first, and more quickly. That would not have been easy; much of the zoo discussion assumes the concepts introduced and expounded in Part I, “Design decisions.”

2. Book writing has logarithmic convergence. Checking the last few uncertain facts, fixing the last few glitched figures, verifying the last few obscure references—these tasks take inordinate proportions of the total effort. The hardest little tasks get put off until the end.