Xref: utzoo comp.arch:4633 comp.edu:1146
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!pasteur!ucbvax!ucdavis!iris!matloff
From: matloff@iris.ucdavis.edu (Norm Matloff)
Newsgroups: comp.arch,comp.edu
Subject: Re: Computer Architecture and Organization (the class)
Message-ID: <1892@ucdavis.ucdavis.edu>
Date: 5 May 88 18:06:33 GMT
References: <3996@medusa.cs.purdue.edu>
Sender: uucp@ucdavis.ucdavis.edu
Reply-To: matloff@iris.UUCP (Norm Matloff)
Distribution: na
Organization: U.C. Davis - College of Engineering
Lines: 49
Keywords: textbook

In article <3996@medusa.cs.purdue.edu> tlh@cs.purdue.EDU (Thomas L Hausmann) writes:
>
>    While searching for reasonable texts, another person in our dept
>    showed me a text by Sajjan G. Shiva, _Computer Design and Architecture_,
>    Little, Brown & Company.
>
>    What (if any) experiences do people have using this text?
>
>    -Tom

I've used Shiva, but only once, due to deficiencies I will explain
below.

On the plus side, Shiva is the first and only text I've ever seen
that the students really like.  Even Tanenbaum is less well-received
(possibly because it's difficult for students in an *introductory*
level course to fully appreciate his "levels" concept).

Another plus is that some of the exercises are quite good.

On the minus side, the book deals too much with implementation of
CPU's, relative to what it does otherwise.  There is not much at
all on true "architecture" (i.e. choice of instruction sets and
addressing modes), and almost nothing on memory hierarchies, which
I consider a key topic.  

It is my understanding that Shiva is now working on a second edition, 
remedying these problems.

Side note:  In my opinion, almost architecture books are written more
for the author's peers than the students.  The books take an awful lot
of granted, quite often writing in such a way that presumes the
students already have some fairly sophisticated knowledge, in spite
of the book's claim to be "introductory."

Second side note:  Has anyone had the following problems?  Being in
an EECS department, my architecture courses consist of EE students,
CS students and students in a hybrid EE/CS major that we offer.  I
find it very difficult to motivate the EE and CS students.  The EE
students are too used to a course being either "lab type", in which
one produces something tangible, or "math type", in which they can
produce equations; thus the react well to the implementation parts
of my course, but complain that these parts are not 100% of the
course, i.e. they don't like the qualitative stuff such as factors
entering in to choosing an instruction set/addressing modes.  On
the other hand, the CS majors dismiss the whole subject as "hardware",
mistakenly thinking that it is irrelevant to them.  Comments?

    Norm Matloff