Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!sun!ember!dre
From: dre%ember@Sun.COM (David Emberson)
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <51409@sun.uucp>
Date: 30 Apr 88 00:37:31 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc> <4921@bloom-beacon.MIT.EDU> <1671@alliant.Alliant.COM>
Sender: news@sun.uucp
Lines: 28
Summary: SPARC Multiprocessors and Cache Consistency


1)  There is nothing inherent in the SPARC architecture that requires the use
    of a virtual cache to obtain high performance.

2)  It is possible to implement snoopy caches with caches that appear to the
    processors as virtual caches.  'Nuff said.

3)  We have a very good architectural solution to this problem for SPARC
    which we are developing now.  We are not yet prepared to go public with it
    but it has been presented to some selected customers on a non-disclosure
    basis.  It is somewhat frustrating to us not to have an announced solution,
    but we'd rather do it right than do something that does not scale well
    (Yes, I did get my hands on the 88200 data sheet!).  All I can say is that
    your patience will be rewarded.

4)  When the pieces are in place, you can bet that the technology will be
    open (i.e. available to all) and will embrace the concept of standard-
    ization that is so dear to us here at Sun.  In other words, it is the
    stated policy of the company that we will make the components available
    so that if you want to build a SPARC machine--even one that competes with
    ours--Sun will encourage you to do so.  A license from Sun is not required
    to use SPARC components.

I may be shot for talking about this stuff, but I think it is important to
the success of SPARC that Sun not be perceived as ignoring this important
technology.  Support for multiprocessors has already been announced as a
deliverable item in Phase III of the AT&T-Sun Unix merge.

		Dave Emberson (dre@sun.com)