¼ÆËã»úϵͳ£º¼¯³É·½·¨£¨Ó¢Îİ棩

.2.4.4 endianness 30
2.4.5 packing of operands and alignment of word operands 32
2.5 high-level data abstractions 35
2.5.1 structures 35
2.5.2 arrays 35
2.6 conditional statements and loops 37
2.6.1 if-then-else statement 38
2.6.2 switch statement 40
2.6.3 loop statement 41
2.7 checkpoint 42
2.8 compiling function calls 42
2.8.1 state of the caller 43
2.8.2 remaining chores with procedure calling 46
2.8.3 software convention 47
2.8.4 activation record 54
2.8.5 recursion 54
2.8.6 frame pointer 55
2.9 instruction-set architectural choices 58
2.9.1 additional instructions 58
2.9.2 additional addressing modes 58
2.9.3 architecture styles 59
2.9.4 instruction format 59
2.10 lc-2200 instruction set 62
2.10.1 instruction format 63
2.10.2 lc-2200 register set 65
2.11 issues influencing processor design 66
2.11.1 instruction set 66
2.11.2 influence of applications on instruction set design 67
2.11.3 other issues driving processor design 68
summary 70
exercises 70
bibliographic notes and further reading 74
chapter 3 processor implementation 76
3.1 architecture versus implementation 76
3.2 what is involved in processor implementation? 77
3.3 key hardware concepts 78
3.3.1 circuits 78
3.3.2 hardware resources of the datapath 79
3.3.3 edge-triggered logic 80
3.3.4 connecting the datapath elements 82
3.3.5 toward bus-based design 86
3.3.6 finite state machine (fsm) 89
3.4 datapath design 91
3.4.1 isa and datapath width 93
3.4.2 width of the clock pulse 94
3.4.3 checkpoint 95
3.5 control unit design 95
3.5.1 rom plus state register 96
3.5.2 fetch macro state 99
3.5.3 decode macro state 102
3.5.4 execute macro state: add instruction (part of r-type) 103
3.5.5 execute macro state: nand instruction (part of r-type) 106
3.5.6 execute macro state: jalr instruction (part of j-type) 106
3.5.7 execute macro state: lw instruction (part of i-type) 108
3.5.8 execute macro state: sw and addi instructions (part of i-type) 111
3.5.9 execute macro state: beq instruction (part of i-type) 112
3.5.10 engineering a conditional branch in the microprogram 116
3.5.11 decode macro state revisited 116
3.6 alternative style of control unit design 119
3.6.1 microprogrammed control 119
3.6.2 hardwired control 119
3.6.3 choosing between the two control design styles 121
summary 122
historical perspective 122
exercises 124
bibliographic notes and further reading 128
chapter 4 interrupts, traps, and exceptions 129
4.1 discontinuities in program execution 130
4.2 dealing with program discontinuities 132
4.3 architectural enhancements to handle program discontinuities 135
4.3.1 modifications to fsm 136
4.3.2 a simple interrupt handler 137
4.3.3 handling cascaded interrupts 138
4.3.4 returning from the handler 141
4.3.5 checkpoint 143
4.4 hardware details for handling program discontinuities 143
4.4.1 datapath details for interrupts 143
4.4.2 details of receiving the address of the handler 146
4.4.3 stack for saving/restoring 147
4.5 putting it all together 149
4.5.1 summary of architectural/hardware enhancements 149
4.5.2 interrupt mechanism at work 150
summary 152
exercises 154
bibliographic notes and further reading 155
chapter 5 processor performance and
pipelined processor design 156
5.1 space and time metrics 156
5.2 instruction frequency 160
5.3 benchmarks 161
5.4 increasing the processor performance 165
5.5 speedup 167
5.6 increasing the throughput of the processor 171
5.7 introduction to pipelining 171
5.8 toward an instruction-processing assembly line 172
5.9 problems with a simple-minded instruction pipeline 175
5.10 fixing the problems with the instruction pipeline 176
5.11 datapath elements for the instruction pipeline 178
5.12 pipeline-conscious architecture and implementation 180
5.12.1 anatomy of an instruction passage through the pipeline 181
5.12.2 design of the pipeline registers 184
5.12.3 implementation of the stages 185
5.13 hazards 185
5.13.1 structural hazard 186
5.13.2 data hazard 187
5.13.3 control hazard 200
5.13.4 summary of hazards 209
5.14 dealing with program discontinuities in a pipelined processor 211
5.15 advanced topics in processor design 214
5.15.1 instruction-level parallelism 214
5.15.2 deeper pipelines 215
5.15.3 revisiting program discontinuities in the presence of out-of-order processing 218
5.15.4 managing shared resources 219
5.15.5 power consumption 221
5.15.6 multicore processor design 221
5.15.7 intel core microarchitecture: an example pipeline 222
summary 225
historical perspective 225
exercises 226
bibliographic notes and further reading 231
chapter 6 processor scheduling 233
6.1 introduction 233
6.2 programs and processes 235
6.3 scheduling environments 239
6.4 scheduling basics 242
6.5 performance metrics 245
6.6 nonpreemptive scheduling algorithms 247
6.6.1 first-come first-served (fcfs) 247
6.6.2 shortest job first (sjf) 252
6.6.3 priority 255
6.7 preemptive scheduling algorithms 256
6.7.1 round robin scheduler 259
6.8 combining priority and preemption 264
6.9 meta-schedulers 264
6.10 evaluation 265
6.11 impact of scheduling on processor architecture 267
summary and a look ahead 268
linux scheduler¡ªa case study 270
historical perspective 273
exercises 275
bibliographic notes and further reading 276
chapter 7 memory management techniques 277
7.1 functionalities provided by a memory manager 278
7.2 simple schemes for memory management 280
7.3 memory allocation schemes 285
intel¡¯s memory architecture 312
exercises 314
bibliographic notes and further reading 315
chapter 8 details of page-based
memory management 316
8.1 demand paging 316
8.1.1 hardware for demand paging 317
8.1.2 page fault handler 318
8.1.3 data structures for demand-paged memory management 318
8.1.4 anatomy of a page fault 320
7.3.1 fixed-size partitions 286
7.3.2 variable-size partitions 287
7.3.3 compaction 289
7.4 paged virtual memory 290
7.4.1 page table 293
7.4.2 hardware for paging 295
7.4.3 page table setup 296
7.4.4 relative sizes of virtual and physical memories 296
7.5 segmented virtual memory 297
7.5.1 hardware for segmentation 303
7.6 paging versus segmentation 303
7.6.1 interpreting the cpu-generated address 306
summary 308
historical perspective 309
multics 311
8.2 interaction between the process scheduler and memory manager 324
8.3 page replacement policies 326
8.3.1 belady¡¯s min 326
8.3.2 random replacement 327
8.3.3 first in first out (fifo) 327
8.3.4 least recently used (lru) 329
8.3.5 second chance page replacement algorithm 333
8.3.6 review of page replacement algorithms 336
8.4 optimizing memory management 336
8.4.1 pool of free page frames 336
8.4.2 thrashing 338
8.4.3 working set 340
8.4.4 controlling thrashing 341
8.5 other considerations 343
8.6 translation lookaside buffer (tlb) 343
8.6.1 address translation with tlb 344
8.7 advanced topics in memory management 346
8.7.1 multi-level page tables 346
8.7.2 access rights as part of the page table entry 348
8.7.3 inverted page tables 349
summary 349
exercises 350
bibliographic notes and further reading 352
chapter 9 memory hierarchy 353
9.1 the concept of a cache 354
9.2 principle of locality 355
9.3 basic terminologies 355
9.4 multilevel memory hierarchy 357
9.5 cache organization 360
9.6 direct-mapped cache organization 360
9.6.1 cache lookup 363
9.6.2 fields of a cache entry 365
9.6.3 hardware for a direct-mapped cache 366
9.7 repercussion on pipelined processor design 369
9.8 cache read/write algorithms 370
9.8.1 read access to the cache from the cpu 370
9.8.2 write access to the cache from the cpu 370
9.9 dealing with cache misses in the processor pipeline 375
9.9.1 effect of memory stalls due to cache misses on pipeline performance 376
9.10 exploiting spatial locality to improve cache performance 377
9.10.1 performance implications of increased block size 383
9.11 flexible placement 384
9.11.1 fully associative cache 385
9.11.2 set associative cache 387
9.11.3 extremes of set associativity 387
9.12 instruction and data caches 392
9.13 reducing miss penalty 393
9.14 cache replacement policy 394
9.15 recapping types of misses 396
9.16 integrating tlb and caches 399
9.17 cache controller 400
9.18 virtually indexed physically tagged cache 401
9.19 recap of cache design considerations 404
9.20 main memory design considerations 405
9.20.1 simple main memory 405
9.20.2 main memory and bus to match cache block size 406
9.20.3 interleaved memory 407
9.21 elements of modern main memory systems 408
9.21.1 page mode dram 413
9.22 performance implications of memory hierarchy 415
summary 416
memory hierarchy of modern processors¡ªan example 418
exercises 419
bibliographic notes and further reading 422
chapter 10 input/output and stable storage 423
10.1 communication between the cpu and the i/o devices 423
10.1.1 device controller 424
10.1.2 memory mapped i/o 425
10.2 programmed i/o 427
10.3 dma 429
10.4 buses 432
10.5 i/o processor 433
10.6 device driver 434
10.6.1 an example 436
10.7 peripheral devices 438
10.8 disk storage 440
10.8.1 the saga of disk technology 448
10.9 disk scheduling algorithms 451
10.9.1 first-come-first-served (fcfs) 453
10.9.2 shortest seek time first (sstf) 453
10.9.3 scan (elevator algorithm) 453
10.9.4 c-scan (circular scan) 455
10.9.5 look and c-look 455
10.9.6 disk scheduling summary 457
10.9.7 comparison of the algorithms 458
10.10 solid state drive 459
10.11 evolution of i/o buses and device drivers 461
10.11.1 dynamic loading of device drivers 463
10.11.2 putting it all together 463
summary 466
exercises 466
bibliographic notes and further reading 468
chapter 11 file system 469
11.1 attributes 469
11.2 design choices in implementing a file system
on a disk subsystem 476
11.2.1 contiguous allocation 477
11.2.2 contiguous allocation with overflow area 480
11.2.3 linked allocation 480
11.2.4 file allocation table (fat) 481
11.2.5 indexed allocation 483
11.2.6 multilevel indexed allocation 485
11.2.7 hybrid indexed allocation 486
11.2.8 comparison of the allocation strategies 490
11.3 putting it all together 491
11.3.1 i-node 497
11.4 components of the file system 498
11.4.1 anatomy of creating and writing files 499
11.5 interaction among the various subsystems 500
11.6 layout of the file system on the physical media 503
11.6.1 in memory data structures 507
11.7 dealing with system crashes 508
11.8 file systems for other physical media 508
11.9 a glimpse of modern file systems 509
11.9.1 linux 509
11.9.2 microsoft windows 515
summary 517
exercises 518
bibliographic notes and further reading 520
chapter 12 multithreaded programming
and multiprocessors 521
12.1 why multithreading? 522
12.2 programming support for threads 523
12.2.1 thread creation and termination 523
12.2.2 communication among threads 526
12.2.3 read-write conflict, race condition, and nondeterminism 528
12.2.4 synchronization among threads 533
12.2.5 internal representation of data types provided by the threads library 540
12.2.6 simple programming examples 541
12.2.7 deadlocks and livelocks 546
12.2.8 condition variables 548
12.2.9 a complete solution for the video processing example 553
12.2.10 discussion of the solution 554
12.2.11 rechecking the predicate 556
12.3 summary of thread function calls and threaded programming concepts 559
12.4 points to remember in programming with threads 561
12.5 using threads as software structuring abstraction 561
12.6 posix pthreads library calls summary 562
12.7 os support for threads 565
12.7.1 user level threads 567
12.7.2 kernel-level threads 570
12.7.3 solaris threads: an example of kernel-level threads 572
12.7.4 threads and libraries 573
12.8 hardware support for multithreading in a uniprocessor 574
12.8.1 thread creation, termination, and communication among threads 574
12.8.2 inter-thread synchronization 575
12.8.3 an atomic test-and-set instruction 575
12.8.4 lock algorithm with test-and-set instruction 577
12.9 multiprocessors 578
12.9.1 page tables 579
12.9.2 memory hierarchy 580
12.9.3 ensuring atomicity 582
12.10 advanced topics 583
12.10.1 os topics 583
12.10.2 architecture topics 596
12.10.3 the road ahead: multicore and many-core
architectures 610
summary 612
historical perspective 612
exercises 614
bibliographic notes and further reading 617
chapter 13 fundamentals of networking
and network protocols 620
13.1 preliminaries 620
13.2 basic terminologies 621
13.3 networking software 626
13.4 protocol stack 628
13.4.1 internet protocol stack 628
13.4.2 osi model 631
13.4.3 practical issues with layering 632
13.5 application layer 632
13.6 transport layer 634
13.6.1 stop-and-wait protocols 636
13.6.2 pipelined protocols 640
13.6.3 reliable pipelined protocol 642
13.6.4 dealing with transmission errors 647
13.6.5 transport protocols on the internet 648
13.6.6 transport layer summary 651
13.7 network layer 652
13.7.1 routing algorithms 653
13.7.2 internet addressing 658
13.7.3 network service model 663
13.7.4 network routing versus forwarding 668
13.7.5 network layer summary 668
13.8 link layer and local area networks 670
13.8.1 ethernet 670
13.8.2 csma/cd 671
13.8.3 ieee 802.3 673
13.8.4 wireless lan and ieee 802.11 674
13.8.5 token ring 675
13.8.6 other link-layer protocols 676
13.9 networking hardware 678
13.10 relationship between the layers of the protocol stack 683
13.11 data structures for packet transmission 685
13.11.1 tcp/ip header 687
13.12 message transmission time 688
13.13 summary of protocol-layer functionalities 694
13.14 networking software and the operating system 695
13.14.1 socket library 695
13.14.2 implementation of the protocol stack in the operating system 697
13.14.3 network device driver 697
13.15 network programming using unix sockets 699
13.16 network services and higher-level protocols 706
summary 708
historical perspective 709
from telephony to computer networking 709
evolution of the internet 712
pc and the arrival of lan 713
evolution of lan 713
exercises 715
bibliographic notes and further reading 718
chapter 14 epilogue: a look back at the journey 720
14.1 processor design 720
14.2 process 720
14.3 virtual memory system and memory management 721
14.4 memory hierarchy 722
14.5 parallel system 722
14.6 input/output systems 722
14.7 persistent storage 723
14.8 network 723
concluding remarks 723
appendix: network programming with unix sockets 724
bibliography 736

.¡¡¡¡4.Parallel System: Computer architecture is a fast-changing field. Chip density, proces sor speed, memory capacity, etc., have all been showing exponential growth over the last two decades and are expected to continue that trend for the foreseeable future. Parallel processing is no longer an esoteric concept reserved for supercomputers. With the advent of multicore technology that houses multiple CPUs inside a single chip, par allelism is becoming a commodity Therefore, understanding the hardware and soft ware issues surrounding parallelism is necessary to answer the question "What is inside a box?" This module deals with operating systems issues and the corresponding archi tectural features in multiprocessors for supporting parallel programming (Chapter 12).
¡¡¡¡We expect Chapter 12 to require six hours of classroom instruction, with two hours of recitation help.
¡¡¡¡5. Networking: In the world we live m, a box is almost useless unless it is connected to the outside world. The multiplayer video game (introduced in Chapter 1), with your friends as fellow players on the network, is a nice motivating example, but even in our everyday mundane activities, we need the network for e-mail, web browsing, etc. What distinguishes the network from other input/output devices is the fact that your box is now exposed to the world! You need a language to talk to the outside world from your box and deal with the vagaries of the network, such as temporary or permanent disconnections. This module deals with the evolution of networking hardware, and the features of the network protocol stack (which is part of the operating system) for dealing with the vagaries of the network (Chapter 13).
¡¡¡¡We expect Chapter 13 to require six hours of classroom instruction, with two hours of recitation help.
¡¡¡¡In a nutshell, Chapters 2 through 10 will require one week ol instruction each; Chapters 11, 12 and 13 will require two weeks of instruction each, rounding up a 15-week semester. The hardware and software issues for each of the five modules are treated together in this textbook. The suggested pathway above through the material follows this treatment.
¡¡¡¡It is possible to tilt the coverage unevenly between architecture and operating systems topics if one so chooses, without loss of continuity Let us consider the processor module. Chapters 3 and 5 deal with the hardware implementation issues of the processor. For a course that is more OS-oriented, Chapter 5, which deals with pipelined processor implementation (starting from Section 5.7), may be lightly covered or skipped altogether (depending on time constraints), without loss of continuity Similarly, in a course that is more architecture oriented, Chapter 6, dealing with processor scheduling issues, may be skipped altogether, without loss of continuity.
¡¡¡¡In the memory module, Chapter 8 deals with details of page-based memory management, from an OS perspective. An architecture-oriented course could skip this chapter if it so chooses, without loss of continuity Similarly, an OS-oriented course may choose to tone down the detailed treatment of cache memories in Chapter 9.
¡¡¡¡In the storage module, an architecture-oriented course may choose to tone down the treatment of file systems coverage in Chapter 11, without concern over loss of continuity.
¡¡¡¡In the parallel module (Chapter 12), an architecture-oriented course may skip topics such as OS support for multithreading and advanced topics such as muhiprocessor scheduling, deadlocks, and classic problems and solutions in concurrency; similarly, an OS-oriented course may choose to skip advanced topics in architecture, such as multiprocessor cache coherence, taxonomy of parallel machines, and interconnection networks. Given the importance of parallelism, it would be prudent to cover the chapter as completely as possible, subject to time constraints, in any course offering.
¡¡¡¡in the networking module (Chapter 13), an architecture-oriented course offering may skip the detailed treatment of the transport and network layers (Sections 13.6 and 13.7, respectively). An OS-oriented course may choose to cover less of the link layer of the protocol stack (Section 13.8) and the networking hardware (Section 13.9). Where Does This Textbook Fit into the
¡¡¡¡Continuum of CS Curriculum?
¡¡¡¡Figure P.1 shows the levels of abstraction in a computer system. We can try to relate the levels of abstraction in Figure E 1 to courses in a typical CS curriculum. Courses such as basic programming, object-oriented design and programming, graphics, and HCI generally deal with higher layers of abstraction. Typically, computer science and computer engineering cumcula offer courses dealing with the fundamentals of digital electronics and logic design, followed by a course on computer organization that deals purely with the hardware design of a computer. Beyond the computer organization course (moving up the levels of abstraction shown in Figure P 1), most cumcula take a stovepipe approach: distinct courses dealing with advanced concepts in computer architecture, operating systems, and computer networks, respectively.
¡¡¡¡Design of computer systems is such an integrated process today that one has to seriously question this stovepipe approach, especially in the early stages of the development of a student in an undergraduate curriculum in computer science.
¡¡¡¡A course structured around the topics covered in this book is a unique attempt to present concepts in the middle (covering topics in the shaded area of Figure P 1systems software and their relationship to computer architecture) in a unified manner in an introductory systems course. Such a course would serve as a solid preparation for students aspiring to learn advanced topics in computer architecture, operating systems, and networking (Figure P2).
¡¡¡¡The prerequisites for a course structured around the topics covered in this textbook are quite straightforward: basic logic design and programming, using a high-level language (preferably, C). In other words, a fundamental understanding of the levels of abstractions above and below the topics covered in this book (see Figure E 1) is required.
¡¡¡¡There are excellent textbooks that cater to the fundamentals of digital electronics and logic design, as well as fundamentals of programming. Similar(v, there are excellent textbooks that deal with advanced topics in computer architecture, operating Systems. and computer networktug. What is missing is a simplified and integrated introduction to computer systems that serves as the bridge between the fundamentals and the advanced topics. The aim of this textbook is to serve as this bridge.
¡¡¡¡The boundary of computer science as a discipline has expanded. Correspondingly. students coming into this discipline have varied interests. There is a need for CS curricula to offer choices tor students to pursue in their undergraduate careers. At the same time, there is a responsibility to ensure that students acquire "core" knowledge in systems (broadly defined) regardless of these choices. We believe that a course structured around this textbook would fulfill such a core systems requirement. If taught right, it should give ample opportunity for students to pursue deeper knowledge in systems, through further coursework. For example, our recommendation would be to have a course based on this textbook in the sophomore year. In the junior year, the students may be ready to take courses that are more design oriented--specializing in architecture, operating systems, and/or networking--building on thc basic concepts they learned in their sophomore year via this textbook. Finally, in their senior year the students may be able to take more conceptual courses on advanced topics in these areas.
¡¡¡¡The textbook balances the treatment of both architecture and operating systems topics. It is the belief of the authors that students maloring in computer science should get an cqual treatment of the two topics early in their undergraduate preparation, regardless of their career objectives. Certainly, students aspiring to becoming system architects, must understand the interplay between hardware and software, as laid out in this textbook. Even for students aspiring to specialize in software development, such an understanding is essential to becoming bettcr programmers. However, it is up to individual instructors how much emphasis to place on the two topics. Tire good news is that thc textbook allows instructors to go into as much depth as they deem necessary; commensurate with the curricular structure existing in their institutions. For example, it' an instructor chooses to scale back on the arehitecture side, it would be quite easy to tread lightly on the implementation chapters addressing the processor (Chapters 3 and 5), without losing continuity in the discourse. In discussing the structure of this textbook, we have already given similar suggestions for each of the five modules that this textbook comprises.
¡¡¡¡Supplementary Material for Teaching
¡¡¡¡an Integrated Course in Systems
¡¡¡¡The authors fully understand the challenge an instructor faces in teaching an integrated course in computer systems that touches on architecture, operating systenz% and networking.
¡¡¡¡To this end, we make available a set of online resources. Since we have been teaching this course--three offerings in each calendar year for the last 11 years--as a requirement for all computer science majors, we have amassed a significant collection of online resources:
¡¡¡¡1. We have PowerPoint slides for all the topics covered in the course, making preparation and transition (from the stovepipe model) easy.
¡¡¡¡2. A significant project component dovetails each of the five modules. We have detailed project descriptions of several iterations of these projects, along with software modules (such as simulators) for specific aspects of the projects.
¡¡¡¡3. In addition to the problems at the end of each chapter, we have additional problem sets for the different modules of the course, as well as homework problems and midterm and final exams used thus far in the course.
¡¡¡¡Example Project Ideas Included in the Supplementary Material Processor Design
¡¡¡¡Students are supplied with a data path design that is 90% complete. Students complete the data path to help them become familiar with the design. Then they design the microcodebased control logic (using a logic design software such as LogicWorks) for implementing a simple instruction set using the data path. This allows the students to get a good understanding of how a data path functions and to appreciate some of the design tradeoffs. The students get actual circuit design experience and functionally test their design, using the built-in functional simulator of the logic design software.
¡¡¡¡Interrupts and Input/Output
¡¡¡¡Students take the design from the first project and add circuitry to implement an interrupt system. Then they write (in assembly language) an interrupt handler. The circuit design part of the project is once again implemented and functionally simulated using LogicWorks software system. In addition, the students are supplied with a processor simulator that they enhance with the interrupt support, and use it in concert with the interrupt handler, which they write in assembly language. This project not only makes operation of the interrupt system clear, but also illustrates fundamental concepts of low-level device input/output.
¡¡¡¡Virtual Memory Subsystem
¡¡¡¡Students implement a virtual memory subsystem that operates with a supplied processor simulator. The students get the feel for developing the memory-management part of an operating system through this project by implementing and experimenting with different page replacement policies. The project is implemented in the C programming language.
¡¡¡¡Multi-Threaded Operating System
¡¡¡¡Students implement the basic modules of a multithreaded operating system, including CPU and 1/O scheduling queues, on top of a simulator that we supply They experiment with different processor scheduling policies. The modules are implemented in C, using pthreads. The students get experience with parallel programming, as well as exposure to different CPU scheduling algorithms.
¡¡¡¡Reliable Transport Layer
¡¡¡¡Students implement a simple reliable transport layer on top of a simulated network layer provided to them. Issues that must be dealt with in the transport layer include corrupt packets, missing packets, and out-of-order delivery This project is also implemented in C, using pthreads.
¡¡¡¡A Note of Caution
¡¡¡¡We offer one word of caution as we launch on our journey to explore the insides of a computer system: In a textbook that presents computer system design, it is customary to back up concepts with numencal examples to illustrate the concepts. The past is indicative of the future. If there is a constant in the technology landscape, it is change When you buy a new car, the minute it rolls out of the showroom, it becomes a used car. In the same manner, any numbers we may use in the numerical examples as to the speed of the processor, or the capacity of memory, or the transfer rate of peripherals become outdated instantly What endure are the principles, which is the focus of this textbook. A comfort factor is that whereas the absolute numbers may change with time--from megahertz to gigaHertz, and megabytes to gigabytes--the relative numbers stay roughly the same as technology advances, thus making the numerical examples in the textbook endure with time.
¡¡¡¡Acknowledgments
¡¡¡¡We are deeply indebted to several colleagues, nationally and internationally, who have been either directly or indirectly responsible for the creation of this textbook. First and foremost, we would like to thank Yale Patt, who, back in the summer of 2004 when we described the course that we teach at Georgia Tech, told us in his inimitable forceful style that we should write a textbook because there is a crying need for a book that presents the systems concepts in an integrated manner. We can honestly say that, but for his encouragement, we may not have embarked on this path. Our colleagues at other institutions who deserve special mention for encouraging us to write this textbook include jim Goodman (University of Wisconsin-Madison and University of Auckland, New Zealand), Liviu Iftode (gutgers University), Phil McKinley (Michigan State University), and Anand Sivasubramaniam (Pennsylvania State University and TCS). We are particularly thankful to Jim Goodman for his careful reading of an early draft of the manuscript and providing detailed feedback that helped improve the discourse tremendously. Besides these folks, we received much positive reinforcement for our project from several colleagues in other institutions who helped to get us started.
¡¡¡¡The first step was creating a manuscript for internal consumption by students at Georgia Tech. We cannot thank the students of CS 2200 at Georgia Tech enough. Ihe feedback from several generations of students, who have used the online version of this textbook since the spring of 2005, has been immensely useful in improving the presentation clarity, refining specific worked-out examples in the text, providing historical pointers that would interest the reader, and other contnbutions. In addition, three undergraduate students helped with some of the artwork in this textbook: Kristin Champion, John Madden, and Vu Ha.
¡¡¡¡Several colleagues in the College of Computing, including Nate Clark, Tom Conte, Constantine Dovrolis, Gabriel Loh, Ken Mackenzie, and Milos Prvulovic, have given suggestions and insightful comments that have helped clarify the discourse in this textbook. We owe a lot to Constantine Dovrolis for suggestions and feedback on early drafts of the networking chapter that have helped improve both the content and the ordering of its presentation in that chapter. Ken Mackenzie~ suggestions helped us to come up with a simple control regime for processor design in Chapter 3. Tom Come gave detailed comments on the pipelining chapter that helped in improving the clarity and the content. Eric Rotenberg of North Carolina State University provided very useful feedback on early drafts of the pipelining chapter. Junsuk Shin wrote the simple client-server socket code that appears in the appendix. Our special thanks go to all of them.
¡¡¡¡We wish to thank Georgia Tech, and the vision of the College of Computing that encourages such creauve thinking on the teaching side. Indeed, it is the revision of the entire undergraduate curriculum back in 1996 which started us on the path of looking critically at how we teach our undergraduates and understanding what we are missing in the curriculum that ultimately led us to develop a first course in systems as an integrated offering spanning architecture, operating systems, and networking.
¡¡¡¡Being novices at book publishing, we turned to successful textbook authors to learn from their experiences. Yale Part (University of Texas), Jim Kurose (University of Massachusetts), Jim Foley (Georgia Tech), Andy van Dam (Brown University), Sham Navathe (Georgia Tech), Rich LeBlanc (Georgia Tech), and Larry Snyder (University of Washington) deserve special mention. We cannot thank them enough for their generosity in sharing their experiences as authors and guiding us through the various aspects of book publishing, including choosing a publisher, working with an editor, framing questions for potential reviewers, and effectively using the reviews in revising the manuscript.
¡¡¡¡The manuscript went through several rounds of external review Most of the anonymous reviewers were thoughtful and skillfully surgical in pointing out ways to improve the manuscript. We are extremely grateful for their time and help in shaping the final product.
¡¡¡¡Our special thanks to Addison-Wesley for publishing our textbook. As our manuscript editor in charge of overseeing the review process and giving us feedback on how to improve the manuscript, Matt Goldstein has been superb. His style of looking over our shoulders without being overbeanng is unique. He has been patient with us when we let schedules slip and has been unwavenngly supportive of the vision behind this book project. Our thanks to Marilyn Lloyd, senior production manager at Pearson, who was in charge of our textbook production. Our thanks go also to Jeff Holcomb, Chelsea Bell, and Dan Parker of Pearson. As the project manager overseeing the day-to-day details of the production process, Dennis Free of Aptara and the Aptara staff, including Jawwad Ali Khan and Rajshri Walia, and Brian Baker of Write With, Inc., deserve special mention for bringing the production of this book to fruition in a timely manner.
¡¡¡¡Finally, we would like to thank our families for their love, understanding, and support, which sustained us throughout the writing of this book. As an aside, Umakishore's father was a famous novelist (with the pen-name "Umachandran") with several fictional books in Tamil to his credit; memories of him served as an inspiration for undertaking this book-writing project.
¡¡¡¡Umakishore Ramachandran
¡¡¡¡William D. Leahy, Jr.
¡¡¡¡