Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!uflorida!haven!rutgers!njin!princeton!phoenix!mbkennel
From: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Newsgroups: comp.arch
Subject: Re: One aspect of bandwidth (backplane bus)
Message-ID: <7794@phoenix.Princeton.EDU>
Date: 17 Apr 89 23:54:33 GMT
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <17298@cup.portal.com>
Reply-To: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Distribution: na
Organization: Princeton University, NJ
Lines: 22

In article <17298@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>Though it's done for different reasons, Macintosh is a sign of times to
>come:  all the (high-speed) main memory is "special," and is right next
>to the CPU/cache.  What do you do for multiprocessors? Build that ECL bus
>and charge several $million.

Excuse me, I'm a complete novice in this area, but is it necessary that
_all_ the memory of each processor be shared, and thus be on a very
fast and expensive bus?  Why can't the bulk of each process' memory
(most of the data, and all of the instructions) be local, and you have
to explicitly ask for shared memory space, with the understanding that access
will be significantly slower.  Transferring data would be faster than
message-type systems, like a connection machine.

I guess that in this scheme, there would be some extra physical memory
riding on the bus for the shared data, but if one really didn't want
to waste anything, is it possible to have a software-selectable but
physically implemented device to configure banks of real memory to
individual processors  or shared pool?

Matt Kennel
   mbkennel@phoenix.princeton.edu