[comp.edu] Comp. Architecture & Organization

tlh@cs.purdue.EDU (Thomas L Hausmann) (04/28/88)

New questions for discussion.

  o  What goes into a "Computer Architecture and Organization" class?

  o  What are good texts for such classes?  

  o  To what extent should "gate level logic" be discussed?

Basically, I am interested opinions from the net because most references to "what
should be covered" are dated and I would like to teach an "updated" course
this Fall.  I have already done some looking at texts but none have satisfied me 
yet.

-Tom

-------------------------------------------------------------------------------
Tom Hausmann       Dept. of Computer Sciences     Purdue University
tlh@medusa.cs.purdue.edu     | 
...!purdue!tlh               |  

eugene@pioneer.arpa (Eugene N. Miya) (04/28/88)

In article <3952@medusa.cs.purdue.edu> tlh@cs.purdue.EDU (Thomas L Hausmann) writes:
>  o  What are good texts for such classes?  

I've just about summarized the counts.  As an unexpected bonus, several
people recommended architecture books.  I present these now.

Note: one correspondent noted (quite truly):
Most of the computers above are really all about the same.

One person wrote:
Jean-Loup Baer, "Computer Systems Architecture", Computer Science Press; 1980

Another wrote:
I am not really an architecture person, but my favorite intro to architecture
book is Tanenbaum's "Structured Computer Organization".  The guy is a
supurb writer, one of the best in CS, he really knows what he is talking
about and obviously has a lot of experience teaching.
[I own this, basically, only 3 machines in detail, but well written. It's
makes a good companion to the slighter weaker book on Computer Networks.]

I suggest the following:
I would also like to add Sieworek, Bell and Newell (Computer Stuctures: .*)
while although slightly biased to a DEC view has many good papers like the
IBM/360, Cray, Alto, Burroughs, Illiac, etc.  The problem with this book is
the sheer cost ($$$) and physical mass.

Also notable is Stone's book which has appeared in a new edition.

I believe all these authors read comp.arch (or have read in the past).

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
				soon to be aurora.arc.nasa.gov
at the Rock of Ages Home for Retired Hackers:
  "Mailers?! HA!"
  {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
  "Send mail, avoid follow-ups.  If enough, I'll summarize."

mark@hubcap.UUCP (Mark Smotherman) (04/28/88)

Last semester I taught a computer architecture course using W. Stallings,
Computer Organization and Architecture, Macmillian, 1987.  The students
were CS undergrads and entering grad students without the equivalent
architecture background.  All students had the prerequisite of a logic
design / register transfer course; so, I didn't have to deal with this
aspect.

Overall, the Stallings book has the feel of a nice revision of the classic
first edition of J.P. Hayes.  (Hayes, by the way has a second edition out
now, but it retains his EE and somewhat formal perspective - e.g. Turing
machines on p. 5.)  The strengths of Stallings are:

(1) It's very readable.
(2) A brief history is included with excerpts from von Neumann's paper on
    EDVAC and a good description of the IAS machine.
(3) Computer classes `a la Bell, Mudge, and McNamara.
(4) Interconnection categories and bus structures (also `a la Bell, Mudge,
    and McNamara).
(5) Very good I/O chapter.
(6) Good discussions of instruction formats, register and CPU organizations.
(7) Data path and control signals `a la Hamacher, Vranesic, and Zaky, with
    good coverage of microprogramming and bit slice architecture.
(8) Sections on pipelining, multiprocessing, fault-tolerance, and RISC.
(9) Appendix on digital logic.

My two major complaints with the Stallings text are:

(1) The lack of a good chapter on operating system support.  Stallings has
    an overview chapter, but I didn't find it useful.  Instead, I assigned
    for reading the chapter by R.L. Sites out of the second edition of Stone's
    book.  What Sites covers well: sharing vs. separation, interrupts and
    context switching (albeit on older machines), relocation, TLBs, and page
    faults.
(2) No attention to procedure calling and activation record stack support
    in the hardware.  Even though Stallings has an overview of the VAX,
    nothing is said about the use and update of the frame pointer and
    argument pointer.  I gave a handout on the use of LINK and UNLINK on
    the MC68000 (this is covered in an example in Hayes, 2nd ed.).

I understand that Stallings is already preparing a second edition.  Ask your
book rep.

One exercise that I have found to be enlightening after studying a particular
architecture is to have the students get assembly listings from Pascal (or C
or ...) programs.  (For Turbo Pacsal, you have to use DOS debug to get a
disassembly listing.)  Lots of questions come up about "gee, why didn't the
compiler use that whizzo instruction we just studied?" and "why did the
compiler use a second register when it didn't have to?"  Good motivation to
take the compiler course.

The next time I teach architecture, I want to try to use two case studies to
tie software (OS/compiler), instruction set architecture, and implementation
issues together.  One is the use of a cache memory, which is often relegated
to being an implementation issue only.  However, there are considerations
about vitrually-addressed vs. physically-addressed caches, the existence of
a purge/sweep cache instruction, and the OS use of such an instruction.  (Not
to mention software cache protocols.)  The second study is the effect of a
pipeline as it shows through to the instruction set architecture (i.e.
delayed branches) and to the compiler (i.e. instruction scheduling).
-- 
Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634
INTERNET: mark@hubcap.clemson.edu    UUCP: gatech!hubcap!mark

fisher@Alliant.COM (Larry Fisher) (04/28/88)

In article <3952@medusa.cs.purdue.edu> tlh@cs.purdue.EDU (Thomas L Hausmann) writes:
>
>  o  What goes into a "Computer Architecture and Organization" class?

I taught Computer Architecture at the Univ. of Lowell (Lowell, MA) between
1981 and 1986.  At first I used a neat text from Caxton Foster at U of Mass.
titled _Computer Architecture_.  Its main attribute is that it covers from
gate level through some of the classic supercomputers in an understandable
way.  If you want to give your CS students (not EE or CE) students a good
feel for machine architecture and design, this is the book.  In my classes,
I supplemented the book with lesser-known info on the CDC CYBER 205 and
CYBER PLUS.  I also had them design a computer (at the register, bus,
and memory-access level) that had a 22-bit address space, 18 bit words,
and single-word instructions.  It made the students think about what goes
into the designing of a computer :-).

>  o  What are good texts for such classes?  

The latest edition of the text mentioned above is:
	Computer Architecture, 3rd Edition, Caxton C Foster/Thea Iberall,
		Van Nostrand Reinhold Co., ISBN 0-442-27219-7

The text I used the last time I taught the course was one recommended by
a professor friend who was promoting a "top-down systems approach" to 
computer architecture.  That text was:
	Structured Computer Organization, 2nd Edition, Andrew S. Tanenbaum,
		Prentice-Hall, ISBN 0-13-854489-1

This book was good in that it presented an overall picture of how things
work together from the gate level up through the OS and user programs.  It
basically dealt with layers of virtual machines (it scared me at first, I
thought it might be only about IBM:-), but I found out the text was OK):
		Level 5: Problem-oriented language level
			---> Translation (compiler)
		Level 4: Assembly language level
			---> Translation (assembler)
		Level 3: Operating system machine level
			---> Partial interpretation (operating system)
		Level 2: Conventional machine level
			---> Interpretation (microprogram)
		Level 1: Microprogramming level
			---> Microprograms are directly executed
			     by the hardware
		Level 0: Digital logic level


>  o  To what extent should "gate level logic" be discussed?

It depends on your approach.  The first book (Computer Architecture)
repeatedly referred to digital logic to discuss things like parallel 
processing, array processing, content-addressable memories, and
pipelining.  The second book (Structured Computer Organization) is softer
on those issues; it unfortunately furthers the lack of real understanding
the many CS students have for computer hardware.  It does give a more
balanced approach than the first book, however.  (Just get the students
to buy both books, its only money :-).  

>Basically, I am interested opinions from the net because most references
>to "what should be covered" are dated and I would like to teach an 
>"updated" course this Fall.  

The first book was last revised in 1985, the second in 1984.

-----------------------------------------------------------------------------
Larry Fisher						fisher@alliant.com
Alliant Computer Systems Corp.				(617)486-1449
Littleton, MA  01460
-- 
Larry Fisher						fisher@alliant.com
Alliant Computer Systems				(617) 486-1449

peter@athena.mit.edu (Peter J Desnoyers) (04/29/88)

The original question asked, among other things, whether gate-level
logic is an appropiate topic. My feelings are (based on a course 
taught by Tom Knight at MIT):

If you are going to cover logic gates, you should cover wiring, 
connectors, and cooling, which are just as important in advanced
computer architectures and far less familiar to the students. I
don't think you need to cover much of these topics - just enough
to give the students a healthy respect for the problems.

				Peter Desnoyers
				peter@athena.mit.edu