Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!cmcl2!rutgers!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!seibel
From: seibel@cgl.ucsf.edu (George Seibel)
Newsgroups: comp.arch
Subject: Re: SISC
Message-ID: <11579@cgl.ucsf.EDU>
Date: 6 May 89 06:54:33 GMT
References: <112@centaure.UUCP> <422@unicads.UUCP>
Sender: daemon@cgl.ucsf.edu
Reply-To: seibel@cgl.ucsf.edu. (George Seibel)
Distribution: usa
Organization: Computer Graphics Lab, UCSF
Lines: 58

In article <422@unicads.UUCP> les@unicads.UUCP (Les Milash) writes:
>In article <112@centaure.UUCP> cliff@centaure.UUCP (Clifford Dibble) writes:
>>Single Instruction Set Computer
>>The SISC extends the concept of RISC architecture to the fullest degree
>
>In Dan Hillis's book about the connection machine he calls it "the ultimate
>RISC" cause it has 1 (albeit very powerful) instruction. and he's not joking;
>it's sort of a 16 dimentional hypercube of soft-settable pals-with-sram;
>each instruction tells the (1-bit) alus what to do and who to do it to.
>
>actually, y'all might enjoy reading this book--only take an evening--even
>tho it's an SIMD and we're all into MI?Ds apparently.  
>the machine is really radical, but nevertheless one of the languages (C*) 
>is amazingly normal considering this is a massively parallel SIMD.

Is it *really* radical?  I'm not so sure - it's different than the way we
do things now, but I think we'll be seeing more and more of it.   By the
way, speaking of amazingly normal languages, the thing has a FORTRAN (!)
compiler now.  I've seen code for it, there are some mild extensions,
but I saw nothing wierd.

>the guy always thinks in "the limit as N -> infinity"; it's that perspective
>that kind of turned me off to shared memory machines or to busses (i mean
>isn't it basically true that lim (N->oo) {sharing memory} = starvation?
>(i'm now shudder in fear and donning my asbestos panties cause i realize
>that that's probably a very controversial thing to say (in fact i'd rather
>y'all'd just call back and call me a Sh*thead in all caps rather than have us
>do a big war about it)) but ain't that basically the truth?  shared memory
>works as long as you don't try to share it (that's what snoopy caches
>are hoping for?); message passing works as long as you don't need to pass 
>many; all these approaches we can milk for another order of magnitude or 
>two but basically the problem is very difficult?  right?

Well, I think you've hit a certain nail on the head (the bandwidth problem)
but note that the CM is not a shared memory machine; that's the point of
it.   Each processor has a small amount of memory local to it, sort of
like you stirred the cpus up with the main memory.  This way you don't
have to push either the cpu or memory technology, and you can still have
a nice match between memory bandwidth and cpu power.  It's going to be
a lot easier to keep thousands of 1 mips processors fed using thousands
of parcels of slow memory than it will be to keep four 125 mips ECL RISCS
fed from a single chunk of shared memory.  This has been mentioned in
one way or another approximately a billion times recently in this newsgroup.

>the book re-inspires me that "there are other Very Odd architectures out 
>there waiting to be discovered; some of which are Very Useful".  After all,
>this is the age of Very Unusual Architectured Computers, right?

Hmmm... (putting on my cynic hat) I'm not so sure.  Just try to sell one.
Seems like if anything the industry is getting more conservative.   Markets
are certainly driven by existing software to an almost unhealthy extent,
and this is an influence that works against unusual architectures.   This
is not to say that a really good idea can't make it; it had just better
be Really Good, and you'd better have deep pockets to ride out the long
wait until it catches on.  I happen to think the CM is a Good Idea, and
I second your suggestion that people check out Hillis' book.

George Seibel, UCSF