This book began when I was
assigned to help salvage an undergraduate computer
organization course. The course had suffered years of neglect: it
had been taught by a series of professors, mostly visitors,
who had little or no interest or background in digital hardware,
and the curriculum had deteriorated to a potpourri of
topics that were only loosely related to hardware architectures.
In some semesters, students spent the
entire class studying Boolean Algebra, without even
the slightest connection to actual hardware. In
others, students learned the arcane details of one particular
assembly language, without a notion of alternatives.
Is a computer organization course worth
saving? Absolutely! In many
Computer Science programs, the computer organization course is
the only time students are exposed to fundamental concepts that
explain the structure of the computer they are
programming. Understanding the hardware
makes it possible to construct programs that are more efficient
and less prone to errors. In a broad sense, a basic
knowledge of architecture helps programmers improve program
efficiency by understanding the consequences of programming
choices. Knowing how the hardware works can
also improve the programming process by allowing programmers to
pinpoint the source of bugs
quickly. Finally, graduates need to understand basic
architectural concepts to pass job application tests given by firms
like Intel and Microsoft.
One of the steps in salvaging our
architecture course consisted in looking at
textbooks. We discovered the texts could be divided into
roughly two types: texts aimed at
beginning engineering students who would go on
to design hardware, and texts written for CS students that
attempt to include topics from compilers, operating systems, and
(in at least one case) a complete explanation of how Internet
protocols operate. Neither approach seemed
appropriate for a single, introductory course on the
subject. We wanted a book that (1)
focused on the concepts rather than engineering details
(because our students are not
hardware design); (2)
explained the subject from a
programmer's point of view, and emphasized consequences for
programmers; and (3) did not try to cover several courses'
worth of material. When no text was found, it seemed
that the only solution was to create one.
The text is divided into five parts. Part 1 covers the basics of
digital logic, gates, and data representation. We emphasize the
representation chapter because notions of two's-compliment
arithmetic and ranges of integer values are essential in programming.
Parts 2, 3, and 4 cover the three essential areas of architecture:
processors, memories, and I/O systems. In each case, the chapters give
students enough background to understand how the mechanisms operate and
the consequences for programmers.
Finally, Part 5 covers advanced topics like parallelism, pipelining,
An Appendix describes an important aspect of
the course: a hands-on lab where students can learn by doing. Although
most lab problems focus on programming, students should spend the first
few weeks in lab wiring a few gates on a breadboard. The
equipment is inexpensive (we spent less than fifteen dollars per
student on permanent equipment; students purchase their own set of
chips for under twenty dollars).
We have set up a web site to accompany the book at:
Rajesh Subramanyan has agreed to manage the site, which contains a set
of class presentation materials created by the author as well as a set
created by Rajesh. We invite other instructors to contribute their
The text and lab exercises have been used at Purdue; students have been
extremely positive about both. We received notes of thanks for the text
and course. For many students, the lab is their first experience with
hardware, and they are enthusiastic.
My thanks to the many individuals who contributed to the book. Bernd
Wolfinger provided extensive reviews and made several important
suggestions about topics and direction. Dan Ardelean, James Cernak, and
Tim Korb gave detailed comments on many chapters. Dave Capka reviewed
early chapters. Rajesh Subramanyan taught from the book and provided
his thoughts about the content. In the CS 250 class at Purdue, the
following students each identified one or more typos in the manuscript:
Nitin Alreja, Alex Cox, David Ehrmann, Roger Maurice Elion, Andrew Lee,
Stan Luban, Andrew L. Soderstrom, and Brandon Wuest.
Finally, I thank my wife, Chris, for her patient and careful editing
and valuable suggestions that improve and polish each book.
Douglas E. Comer