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