Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!ihnp4!fortune!rpw3 From: rpw3@fortune.UUCP Newsgroups: net.books Subject: Re: Computer Science Books - (nf) Message-ID: <2305@fortune.UUCP> Date: Wed, 18-Jan-84 23:02:37 EST Article-I.D.: fortune.2305 Posted: Wed Jan 18 23:02:37 1984 Date-Received: Fri, 20-Jan-84 01:33:13 EST Sender: notes@fortune.UUCP Organization: Fortune Systems, Redwood City, CA Lines: 154 #R:uofm-cv:-46100:fortune:22600004:000:8166 fortune!rpw3 Jan 18 19:56:00 1984 Let's see, given Knuth, Brooks, and Dijkstra,... I would rave about the following seven: William A. Wulf, Roy Levin, and Samuel P. Harbison, "HYDRA/C.mmp" This is an essential reference for operating systems and network architects in the 80's, even if the systems they build do not closely reflect the principles presented here. HYDRA/C.mmp was an experimental (but fully functional) multi-processor timesharing computer system built at Carnegie-Mellon (CMU) between 1971 and 1977. C.mmp was the computer (16 PDP-11's plus 32 Mbytes of shared memory); HYDRA was the operating system. The basic protection mechanism was the "typed object" and the "capability" (a kernel protected handle) to apply a operation (procedure) to an object. (The "root" of the system was the object whose type is "Type".) Such UNIX concepts as "read", "write", "execute", "send", "receive", "create", "lookup", "rename", and "delete" are easily mapped into this framework. But HYDRA did not supply these operations; they were supplied by user-level procedures. The file systems, debuggers, scheduler policies, and network interfaces were all (unpriviledged) user level programs. The principle of policy/mechanism separation guided most of the major design decisions. The most valuable feature of the book (besides the introduction of clear models and definitions) is the "Retrospective" section at the end of each chapter and a whole chapter of "Reflections" at the end. Here the authors ruthlessly examine the material just presented from the viewpoint of what they learned, what they would do differently, which assumptions proved out and which did not, and thorny problems that are still not solved. As always, it is helpful to know where others have stumbled (and succeeded). Butler W. Lampson, M. Paul, and H. J. Siegert (editors), "Distributed Systems" This is one of the Springer-Verlag Lecture Notes in Computer Science series, publishing notes from courses (generally given in Europe). The full title is "Distributed Systems: Architecture and Implementation, an Advanced Course". Unlike most of the others in the series, in this one the readability has benefited greatly from Lampson's access to Xerox PARC's Alto/Star fonts and graphics. Even with 20 chapters (500 pages) and over eight contributers the content is well integrated, and nicely surveys what was known (and not known) about distributed systems and networks in the state-of-the-art in 1980. It is still quite up-to-date. After presenting a "distributed system architecture model", the book covers IPC, hardware, link protocols, hierarchy issues, end-to-end IPC, naming, protection, atomic transactions, synchronization, the multi-copy update problem, and applications and their protocols. A view of the layering of a complete application is given in the chapter "Ethernet, Pup, and Violet", which describes a distributed, replicated calendar system. But my favorite chapter is the last, by Ken Thurber, which has section titles: - What we have defined - What we think we know - What we conjecture - What we think we don't know - What we advise - What you should know - What we don't agree upon. This final chapter alone is worth the price of the book, which is cheaper if you get it in the "Springer Study Edition". Dan Siewiorek, Gordon Bell, and Allen Newell, "Computer Structures" Second edition: "Principles and Examples". 926 pages. This is THE classic encyclopedia of computer architecture; it presents a taxonomy of computer structures and examples of machines which fit one or more catagories. Mandatory reading and re-reading for practicing and would-be architects. "All of the machines discussed in this book have actually been constructed and evaluated. The papers, wherever possible, are written by the specific machine architects or people closely associated with the architectures. Several of the machines are presented in elaborate detail, enabling the reader to appreciate the design complexities encountered and design methodologies employed by the architects." Articles include the IBM 360/91, Illiac IV, B5500, Manchester Mark I, PDP-8, Tandem 16, Aloha packet radio, Xerox Alto, PDP-11, CDC 6600, VAX, HP 9845A, IBM System 38, Cray-1, TI ASC, Ethernet, the SYMBOL machine, ARPAnet IMP, Intel 8008 through 8086, and many many more. C. Gordon Bell, J. Craig Mudge, and John E. McNamara, "Computer Engineering" Subtitled "A DEC view of hardware systems design", it is exactly that. From "In the Beginning" (1957) through "The PDP-8 and Other 12-bit Computers" and "The Evolution of the PDP-11" to "VAX-11/780" this book lays out the DEC engineering methodology and style. In the chapter "Impact of Implementation Design Tradeoffs on Performance: The PDP-11, A Case Study" the register/ALU/data-path diagrams are given for every machine from the LSI-11 (PDP-11/03) to the PDP-11/60 with discussion of technology, microcode, tradeoffs, and performance. Papers on caches, buses, threaded code, Register Transfer Modules (later called PDP-14), C.mmp and Cm* (CMU's multi-processors), the PDP-10 (PDP-6, KA-, KI-, and KL-10), and packaging and manufacturing flesh out a feast for historians. Hardware architects would do well to consider the lessons here, especially the "Wheel of Reincarnation" discussed in the section on the DEC 338 display computer. R. C. Holt, "Concurrent Euclid, The UNIX System, and Tunis" Good intro to concurrency. The EUCLID simulation kernel is a good model for simulation systems in general (we have used a "C" adaptation for doing I/O system simulations). The description of the UNIX file system has helped several beginners unscramble the ideas of directories, i-nodes, and files. The model of interrupt handlers as processes is impeccable (Down with interrupts! Bring back the 6600!) and even efficient. The two pages of PDP-11 assembler which is called a "kernel" (EUCLID's use of the word) would be called "save/resume" in UNIX. The idea (and in the case of Tunis, practice) of building systems that can have additional processors added to them without changing anything is much needed in this world of fast micros. David Gries, "The Science of Programming" The ideas and methods of Dijkstra's "Discipline of Programming" made accessible to mere mortals. I must confess I didn't really believe/understand the proof of the loop invariant theorem until I read the version presented here. Full of goodies like a "checklist for understanding a loop" and "ways of weakening a [loop invariant] predicate". The "balloon theory" of loops is great! (You start with a loop predicate [balloon] which includes both the pre-condition and the post-condition, then "deflate the balloon" as you iterate the loop until it just encloses the post-condition.) Tom DeMarco, "Controlling Software Projects" A solid book about software development, and its pitfalls. Subtitled "Management, Measurement, & Estimation", the book opens with "You can't control what you can't measure. In most disciplines the strong linkage between measurement and control is taken for granted. But I fear the idea may be news to many software managers, otherwise rational men and women who harbor an illusion of control, even though they never measure anything." He goes on to discuss WHY we are so poor at measurement and estimating (chiefly the political problem of estimates being used to create incentives). Rather than an estimate being "the most optimistic prediction with non-zero probability of coming true", he proposes "a prediction that is equally likely to be above or below the actual result". My only reservation is that it may be hard to find (upper) management willing to face the truth about their software disasters. (Dijkstra has asked, "How do you tell truths that might hurt?") After all, years after Brooks's Law, we still pour more people on late projects. Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065