Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!necntc!linus!alliant!jeff
From: jeff@Alliant.COM (Jeff Collins)
Newsgroups: comp.arch
Subject: Re: SPARC and multiprocessing
Message-ID: <1699@alliant.Alliant.COM>
Date: 2 May 88 22:51:18 GMT
References: <1521@pt.cs.cmu.edu> <28200135@urbsdc> <4921@bloom-beacon.MIT.EDU> <1671@alliant.Alliant.COM> <623@garth.UUCP>
Reply-To: jeff@alliant.UUCP (Jeff Collins)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 37

In article <623@garth.UUCP> walter@garth.UUCP (Walter Bays) writes:
>In article <1671@alliant.Alliant.COM> jeff@alliant.UUCP (Jeff Collins) writes:
>>	Given that the SPARC must use a virtual cache to get optimal
>>	performance, how does one build a multiprocessor with a SPARC?
>>	As far as I know, no one has solved the virtual cache coherency
>>	problem yet...
>
>Clipper uses 'bus watch' to invalidate references to stale data, when
>used in multiprocessor (including CPU-IOP) modes, and when using
>'copy-back' (as opposed to write-through) cache modes.  The newly
>announced Motorola 88000 uses a similar scheme, called 'bus snoop'.
>
>With SPARC, Clipper without CAMMU chips, or 88000 without CAMMU chips,
>you implement your own cache, and can build whatever you choose.
>-- 

	Actually I am familiar with the Clipper and the 88000.  I know how they
	support multiprocessing.  The point here was that these chips put the
	cache after the MMU.  This means that the caches contain physical
	address and the tag stores record physical addresses.  When an address
	goes across the bus it is not a big deal to "watch it" and determine
	if the address is in the cache or not.  Current implementations of the
	SPARC, on the other hand, get optimal performance using a virtual
	cache - ie. the cache is BEFORE the MMU.  It is a much more
	complicated procedure to "watch" these addresses.  With a virtual
	cache, each physical address on the bus must first be translated to
	it's corresponding virtual address through some sort of reverse TLB,
	then the address can be provided to the bus watcher to see if the data
	is in the cache.

	This presents a number of problems that are not present in the case of
	the 88000 or the Clipper (or any other micro that uses physical
	caches).  One of the problems is aliasing - this is when multiple
	virtual addresses refer to the same physical address.  In order to
	properly snoop, all of the aliases must be checked for in the cache.
	Another problem, is simply the implementation of the reverse TLB -
	what happens when the reverse TLB misses?  Which set of page tables
	should the TLB walk?