Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!udel!burdvax!psuvax1!gondor.cs.psu.edu!przemek
From: przemek@gondor.cs.psu.edu (Przemyslaw Klosowski)
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <3530@psuvax1.psu.edu>
Date: 4 May 88 00:39:23 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc> <4921@bloom-beacon.MIT.EDU> <1671@alliant.Alliant.COM> <51321@sun.uucp>
Sender: netnews@psuvax1.psu.edu
Reply-To: przemek@gondor.cs.psu.edu (Przemyslaw Klosowski)
Organization: Penn State University
Lines: 16

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?"
IMHO the virtual cache ($) has serious advantages, one of which is that separate
TLB (which is nothing else but separate cache for translation data) is not 
necessary. And of course convenient overlapping of $ access  with V->R 
translation.  

				przemek@psuvaxg.bitnet
				psuvax1!gondor!przemek
 

				przemek@psuvaxg.bitnet
				psuvax1!gondor!przemek