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 
focused  on
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,
and performance.
            
     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).
            
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