Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!ihnp4!ucbvax!rosemary.Berkeley.EDU!dougj
From: dougj@rosemary.Berkeley.EDU.berkeley.edu (Doug Johnson)
Newsgroups: comp.arch
Subject: Re: Today's dumb question...
Message-ID: <23492@ucbvax.BERKELEY.EDU>
Date: 1 Apr 88 19:44:58 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: dougj@rosemary.Berkeley.EDU.UUCP (Doug Johnson)
Organization: University of California, Berkeley
Lines: 24


 >In article <503@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes:
 >>                                Now for _tightly coupled_
 >> multiprocessing, one needs some sort of atomic test-and-set instruction. 
 >> How do the various RISC chips provide this function, with LOCK prefixes,
 >> or with some other technique?
 >> Greg Franks

 >RISC people (as I discovered at ASPLOS II, San Jose, Oct 87) would
 >rather not speak of parallel processing. Reminds me of the ostrich.
 >Ask them - "how are you going to maintain cache coherency, TLB
 >flushing, accesses integrity, etc in a parallel processing system?"
 >and they will say "why do you want parallel processing when one
 >RISC machine is so much faster than even parallel CISCs?"

 >I would prefer a philosophy that allows for clean parallelisability
 >over any single cpu speedups.

Take a look at the SPUR project being done at UC Berkeley.  (There is
an overview article in the November 1986 issue of Computer.)  It is a
RISC designed to do tightly coupled, coarse grained,  multiprocessing.
It addresses cache coherency (with snoopy caches), TLB flushing (no
TLB, address translation is done in the cache), has a test_and_set,
etc.   -- Doug