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: <3529@psuvax1.psu.edu>
Date: 4 May 88 00:33:25 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc> <4921@bloom-beacon.MIT.EDU> <1671@alliant.Alliant.COM>
Sender: netnews@psuvax1.psu.edu
Reply-To: przemek@gondor.cs.psu.edu (Przemyslaw Klosowski)
Organization: Penn State University
Lines: 21

In article <1671@alliant.Alliant.COM> jeff@alliant.UUCP (Jeff Collins) writes:
>
>	As far as I know, no one has solved the virtual cache coherency
>	problem yet...
>
See ``An in-cache address translation mechanism'' by D.A. Wood et all. in: 
Proc 13th annual ACM/IEEE symposium on comp. arch. Tokyo June 1986.
They describe SPUR solution to the problem. Basically it consists of forcing 
Global Virtual address (which is almost but not quite virtual addr) to be the
samo for all shared data. 
Other solutions used Reverse TLB's to retrieve virtual address and then use 
normal (i.e. bus snooping techniques). 
Last but not least, why not delegate responsibility to software? It is only 
a question of finding a convenient paradigm.

				przemek@psuvaxg.bitnet
				psuvax1!gondor!przemek



				przemek@psuvaxg.bitnet
				psuvax1!gondor!przemek