Path: utzoo!mnetor!uunet!husc6!linus!alliant!jeff
From: jeff@Alliant.COM (Jeff Collins)
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <1680@alliant.Alliant.COM>
Date: 29 Apr 88 19:23:09 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc> <4921@bloom-beacon.MIT.EDU> <1671@alliant.Alliant.COM> <51321@sun.uucp>
Reply-To: jeff@alliant.UUCP (Jeff Collins)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 48

In article <51321@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>> 	Given that the SPARC must use a virtual cache to get optimal
>> 	performance, how does one build a multiprocessor with a SPARC?
>
>Excuse me?  Where is it "given that the SPARC must use a virtual cache to get
>optimal performance?"  It is the case that the SPARC requires some form of very
>fast memory to get optimal performance, but that's true of a hell of a lot of
>machines these days.  The virtual cache permits you to bypass the MMU on a
>cache hit, but I don't know that this is *required* for SPARC - or for any of a
>number of other microprocessor architectures.
>
>It may be the case that with the current SPARC implementations, with no on-chip
>MMU, that it's easier to get high performance with a virtual cache than with a
>physical cache, or even that you can't get optimal performance *for those
>implementations* with a physical cache (although I suspect the latter is not
>true).  This certainly doesn't say that the SPARC *architecture* requires a
>virtual cache.
>

	Sorry, Guy but you misunderstood the purpose of my posting.  I was not
	attempting to attack the SPARC.  I am simply attempting to see if
	anyone has given any thought the the problem of using the SPARC with a
	virtual cache in a multiprocessor.  It is my understanding (and I
	admit that you are closer to the issue than I am) that it is not easy,
	and may not be possible, to put a virtual to physical translation
	before the SPARC's cache and still get no-wait-state performance.
	(Please note that I didn't say that it was impossible to do this, only
	that the performance would be degraded.)

	If one looks at other current microprocessors (NS32532,	Mot. 88000,
	MIPS 3000, etc.) they all have standard MMUs available with the part
	and have a fairly credible story of how to make them perform in a
	multiprocessor.  There is no standard MMU (to my knowledge) available
	for the SPARC, and at least the current implementations seem to have a
	major drawback when attempting to put them in a multiprocessor.

	The question still remains - if you want to run the SPARC with a
	virtual cache in a multiprocessor - how do you do it?  Other questions
	that get to the same issue are:

	    - How does one get no-wait-state performance in a multiprocessor
	      using the SPARC?
	    - Is there a standard MMU going to be available, and how will it
	      work with a multiprocessor?
	    - Is there a solution to the virtual cache problems?
	    - Is there an announced version of the SPARC that allows time
	      between address-ready and data-ready to have an MMU before the
	      cache?