Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!orion.cf.uci.edu!oberon!sm.unisys.com!ucla-cs!marc
From: marc@oahu.cs.ucla.edu (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: i860 CPU information
Keywords: i860 N10
Message-ID: <21972@shemp.CS.UCLA.EDU>
Date: 18 Mar 89 22:25:38 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU> <3024@alliant.Alliant.COM> <21784@shemp.CS.UCLA.EDU> <3041@alliant.Alliant.COM>
Sender: news@CS.UCLA.EDU
Reply-To: marc@cs.ucla.edu (Marc Tremblay)
Distribution: usa
Organization: UCLA Computer Science Department
Lines: 19

In article <3041@alliant.Alliant.COM> jeff@alliant.Alliant.COM (Jeff Collins) writes:
>	Actually I know how directory based cache coherency works, but you
>still need the ability to invalidate the internal cache from external logic.
>The memory will detect that a cache location on a processor needs to be
>invalidated and send an invalidate signal (with the physical address) to
>the CPU card.  The CPU card must then (because the internal cache is virtual)
>do a reverse TLB lookup and then signal the internal cache to invalidate.  

Using a directory based cache coherency method with processors that do not
have the capability to have their internal cache entries invalidated externally,
the memory controller has to send a vector interrupt to one of the 
the processors which can then invalidate the correct cache line.
I don't know how much flexibility the "flush" instruction of the i860 offers 
(the data sheet does not say much), but it should be possible to do it,
if not, then too bad :-) .

					Marc Tremblay
					marc@CS.UCLA.EDU
					Computer Science Department, UCLA