Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.arch
Subject: Re: i860 CPU information
Message-ID: <29@microsoft.UUCP>
Date: 22 Mar 89 14:36:06 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU> <3024@alliant.Alliant.COM> <21784@shemp.CS.UCLA.EDU> <3041@alliant.Alliant.COM> <21972@shemp.CS.UCLA.EDU>
Reply-To: w-colinp@microsoft.uucp (Colin Plumb)
Distribution: usa
Organization: very little
Lines: 28

marc@cs.ucla.edu (Marc Tremblay) wrote:
> 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 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 :-) .

The flush instruction is half a load; it basically forces the data in the
cache line it conflicts with to be written out and removed from the cache.
I believe doing a flush specifying an address already in the cache is
useless; the point is to create a fake address that conflicts with the real
one (using knowledge of how the cache works) and some magic bits in a status
register that let you control which set a cache miss chooses to replace.
(Default is random replacement.)

So, to force a flush of the data at a certain address, you'd have to flush all
4 lines that might contain with that address.  (There's no way to examine
the cache's contents.)  With the status register munging, a bit ugly.

Add my existing comments about the horribleness of the i860's exception
handling, and I don't think the software approach would be acceptably fast.
(BTW, no vectored interrupts.)
-- 
	-Colin (uunet!microsoft!w-colinp)

"Don't listen to me.  I never do." - The Doctor