Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!venera.isi.edu!rod From: rod@venera.isi.edu (Rodney Doyle Van Meter III) Newsgroups: comp.arch Subject: Re: Books to read before thinking about computer architecture Message-ID: <9858@venera.isi.edu> Date: 25 Sep 89 18:23:00 GMT References: <28168@winchester.mips.COM> Reply-To: rod@venera.isi.edu.UUCP (Rodney Doyle Van Meter III) Organization: Information Sciences Institute, Univ. of So. California Lines: 42 I'll stick my neck out and toss up a nice fat one for people to shoot down. Keep in mind that I'e only just begun graduate work in computer engineering, and that before that my experience was very much colored by working with VAXen (and VMS, no less). _Computer Engineering_, Gordon Bell and friends, 1978? Keeping in mind that it's over ten years old and is a broad case study on the DEC way of doing things, this is an interesting book. Pre-RISC, it takes the viewpoint that the VAX is sort of the high point of comp[uter architecture up to that point in time. NOT a book on how to design a computer today. Good historical book going all the way back to the beginning of DEC. _Computer Architecture and Parallel Processing_, Kai Hwang and Faye' A. Briggs, McGraw-Hill, 1984 A good book on the theory of high-level design. Hwang is at USC and is interested in supercomputing, and the book reflects that, though cost issues occassionally come in. They do take a sort of narrow view of SIMD machines, seeing them mainly as vector processors. It seems to be strong on pipelining, which is an important topic in microprocessors these days. It does occassionally reach down to the gate level for such matters as HW implementation of cache replacement policies. It doesn't cover such issues as instruction set design, which I'm interested in, but other than that most of its flaws are that it's already five years old. Work on a second edition has reportedly begun, but it's likely to be a while before it's out. Other than that, I read the SIGARCH notes, and every detailed processor reference I can get my hands on. Here's a question for you: Should the instruction set be the same on different types of multiprocessors as it is on a uniprocessor? Why or why not? Some of the hypercube-esque machines have been built around things like the 68020. It's fast, it's easy, somebody else is out there making the processor faster without you having to do a thing, but is it really, fundamentally, the right idea? --Rod