Computer Architecture: Concepts and Evolution

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.

Since any technical matter must be read pen-in-hand, we have provided exercises that will guide one's study, focus attention on critical points, or explore interesting byways.

ScopeWe distinguish architecture, implementation, and realization as three separable concerns in the construction of anything, including computer systems. This book is about architecture-the property of a system that determines what programs run, and what results they produce. This is the aspect of a system as perceived by the user. Matters of implementation will be touched upon where they interact strongly with architecture, but implementation is not generally covered. Realization is not treated at all.

We are concerned with entire computer systems, but in a detail that diminishes as one goes outward from the central processing unit. That is, we have aimed for completeness in our coverage of central processing unit (CPU) architecture, and of input/output (I/O) subsystems. We have not covered the architecture of I/O devices, except as to their role in overall system architecture. The whole large topic of communications and terminals is similarly discussed only as it affects I/O subsystem design.

New resultsConsidering computer architecture as a separate concern yields many consequences that are not piecemeal publishable. Hence this book contains many results of our original research not previously published at all or not widely available:

In Chapter 1, we demonstrate the use of APL for formal description of architectures (after Falkoff, Iverson, and Sussenguth). This yields a descriptive language which is executable, usable separately to describe the implementation level, allows verification that an implementation and its architecture are consistent, and allows a denotational, rather than operational, semantics.

Chapter 1 also explores the opposing esthetic principles characterizing good architecture, and introduces decision trees as a formal tool for representing architectural choices. All the trees in Part I are components of one unified architecture decision tree.

Chapter 2 introduces the concept of architecture as programming language design and presents a new treatment of the old issue of the optimal level of such languages (for example, RISC vs. object-oriented). Iverson's dual concepts of interpretation and representation are incorporated into a general paradigm.

Chapter 3 treats the issues of machine addressing under a unified concept of naming and progressive name-binding, a concept suggested by F. Don Smith.

Chapter 4 follows Bell and Newell in treating data representation in terms of abstract datatypes.

Chapter 5 provides a unified view of invalid results in terms of the domains and ranges of representation transformations.

Chapter 6 recognizes machine-language Branch operations as sub-primitives and treats all sequencing operations in terms of high-level control structures.

Chapter 7 unifies the treatment of supervisory functions in terms of communicating asynchronous processes.

Chapter 8 similarly treats I/O operations in terms of concurrent asynchronous processes and their processors. The system corollaries of I/O's inherent (1) asynchrony and (2) slowness are set forth.

Overall, the least visible of the new results may prove to be the most useful:

The attempting in Part II of exact descriptions of many architectures in a consistent language, enabling correction and criticism

The tabulation, and comparison, of many specific features over some fifty architectures.

Many of the tables in Part I are columns of one unified architectural property table.

Relationships with other works

Since we were participants in Buchholz's Planning a Computer System 1962, that book and this one reflect the same philosophy. This one is more general, emphasizing comparative studies of techniques across machines from many generations, designers, and manufacturers. It also reflects lessons learned and viewpoints changed since that book.

Bell and Newell's Computer Structures 1971, on the other hand, reflects an independent viewpoint and a different machine-designing tradition. Their treatment is masterful on many points, and they provide the first conceptual framework for computer architecture.

Bell and Newell, and its 1980 successor by Siewiorek, Bell, and Newell, provide a library of machine descriptions to which we often refer for illustration. For a selected sample of machines, we give in the Computer Zoo short sketches in a common format, plus evaluative comment. Some of our sketches cover machines they treat; most cover different and more recent machines. We have rigorously limited our discussions to real machines actually built; this provides a first screening for the utility of innovations.

Hennessy and Patterson's Computer Architecture: A Quantitative Approach 1990 provides a superb discussion of the "converged architecture" whose evolution and convergence is one of our themes. They document four specific instances of the converged architecture, as well as discussing architectural and implementation issues in depth, furnishing much useful data. Their book is an excellent complement to this book.

Each of us has published a related book since we began this joint work. Blaauw's Digital System Implementation 1976 complements this book on the hardware side, treating implementation just as this one treats architecture. Brooks's The Mythical Man-Month 1975, 1995 lies on the software side of this one. Chapters 4-7 of that book deal with the organization and philosophy of the architectural function in a development project. Those chapters treat the process of architecture design. They supplement this book, which treats the content of computer architecture.

Illustrative designs

What should the architect read and study? Applications and machines. Applications as varied as possible, as innovative as possible. These are the raw materials from which he will form his own visions of usefulness.

Why machines? To understand problems, design alternatives, and philosophies. It is sometimes fashionable to scorn all past design, seeking only the original, the radical. Experience does not prove this attitude fruitful.

J.S. Bach trained himself by hand-copying the works of his predecessors. As Tovey 1950 says, "There is no branch of music, from Palestrina onwards, conceivably accessible in Bach's time, of which we do not find specimens carefully copied in his own handwriting." Humbling his mind to this detailed study equipped him with technique and furnished his mind with hundreds of ideas. So it is with creative computer design. The most important study of the designer is other people's designs.

We have illustrated the concepts with early computers as well as recent ones. Many parts of the design space were explored in early machines, and not later. It is important for the designer to know what concepts were explored and found unfruitful, and why.

We have described the decisions and attempted to reconstruct the arguments of our predecessors and contemporaries. Since we have lived and practiced through the first two (human) generations of computer architects, we have attempted to collect, summarize, and evaluate all the experiences from 1937 to 1985. This is our legacy to architects now active and those who shall come later.

When reading the professional paper describing the architecture of a new machine, it is often difficult to discern the real design dilemmas, compromises, and struggles behind the smooth, after-the-fact description. It is sometimes possible, though risky, to guess the motives and reasoning of designers. We have occasionally made here such guesses and marked them as such.

We have participated together in the design of three computer architectures, and we have each participated separately in several more. About the motives and reasoning of these we can speak first hand, and we believe it more useful to do so than to hide behind the mask of impersonal professionalism. So we use these experiences to illustrate the general themes and principles of design. The IBM System/360 was the first family of computers in which the architecture was clearly distinguished from the implementations; it figures prominently here. The amount of space used for such systems, especially the 360, is not intended to reflect their relative importance in the history of computer architecture; they are merely the systems we know best.

The examples of the DEC PDP11 and the IBM System/360 illustrate once more the intertwined nature of computer architecture. Just knowing the right solutions is half the problem. The other half is making all the right solutions fit with each other.

Prerequisites

We assume familiarity with certain elements of computer science including: Logical design, number systems, and coding systems

Elementary computer organization, implementation technique, and I/O technology

Computer programming in some machine language

Programming systems, including some knowledge of how assemblers and compilers work

An acquaintance with a modern version of Iverson's APL language (An Appendix summarizes APL.)

Order

The order of topics is designed for the practitioner of computer architecture. Hence the first chapter gives a certain overview and viewpoint of the subject as a whole, addressing the difficult question: What is good computer architecture? Students without design experience will find this viewpoint too general to have much content. We recommend that they read the first chapter lightly, then study the detailed material in Chapters 2-8, and finally return to Chapter 1 for a closer view of the general issues.

The plates

The chapter frontispieces, evocative rather than illustrative, are from Palladio's work, The Four Books of Architecture. In his introduction to the Dover edition (1964), Adolf K. Placzek says:

Andrea Palladio was...the spokesman for the belief in valid rules, in immutable canons, for the belief that there is a correct, a right way to design. ...Palladianism is the conviction, first of all, that a universally applicable vocabulary of architectural forms is both desirable and possible; secondly, that such a vocabulary had been developed by the ancient Romans... and, thirdly, that a careful and judicious use of these forms will result in Beauty. This beauty, according to the Palladians, is therefore not only derived from ideal forms and their harmony; ...it includes the most practical, reasonable solution of the specific problem on hand.

Computers have evolved, over fifty years, a robust "classical" architecture, whose elements produce both an esthetic delight and the most practical solutions to the design problems.

Acknowledgments

We appreciate the contribution of the Guggenheim Foundation, which generously supported Brooks for the book's crucial initial period.

The work has been mightily advanced by our secretaries and editorial assistants, Rebekah Bierly, Victoria Baker, Steven Bellovin, Mary Mayfield, Helga Thorvaldsdottir, Larry Margolese-Malin, Scott Lane, and especially, Alice W. Hoogvliet-Haverkate and Sara Elizabeth Moore Jones.

Mark Smotherman, Pierre Delesalle, Jan Raatgerink, Judy Popelas, Ryutarou Ohbuchi, and Amos Omondi made substantial contributions to the scholarly work as research assistants. Gordon Hill, Richard P. Case, Harvey Cragon Richard Sites, and F. Don Smith helped by meticulous reviews and the teaching of drafts. Joey Tuttle provided the APL font. Kim Blakeley Herring helped design the figures. We are indebted also for many suggestions from the students in our annual class tests since 1977.

David Lines typeset and laid out the book, producing camera-ready copy. As important, he has played a major role in the literary and visual styling, working closely with us and with Addison-Wesley.

We thank our Lord for enabling us to do this work. "And establish thou the work of our hands upon us; yes, the work of our hands, establish thou it" (Psalm 90:17).

Enschede 1996 Chapel Hill

0201105578P04062001