Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!cmcl2!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: i860 CPU information
Keywords: i860 N10
Message-ID: <706@m3.mfci.UUCP>
Date: 15 Mar 89 15:53:16 GMT
References: <1895@oakhill.UUCP> <21570@shemp.CS.UCLA.EDU> <3024@alliant.Alliant.COM> <15213@winchester.mips.COM>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Distribution: usa
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 34

In article <15213@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <3024@alliant.Alliant.COM> jeff@alliant.Alliant.COM (Jeff Collins) writes:
>......
>>:There are policies that do not require this feature at all.
>....
>>	Actually never mind that, how do you switch a process from one
>>	processor to another (I don't count flushing the D-cache on
>>	each context switch as a viable answer)?
>
>As I posted in <15016@winchester>, you have to flush the caches
>on context-switch in a single CPU, much less a multiprocessor.
>

Hmmmm. I'm not sure I understand this, I haven't read your posting
so forgive my ignorance here.

On our single cpu system we use a process id tagged icache and we
assign the process a new hardware "pid" (or "asid", if you prefer :-),
which takes essentially no time. Obviously, on a cmiss the cache 
is written with the hardware pid and on a read this tag is checked
against the current hardware pid.  [ Sorry for boring those of you
that already know this from basic comp.arch 101]

Once you've cycled around all the hardware pids, you *then* have to 
actually flush the cache. But this is only one time in 256,1024 ,etc,etc..

So, I assume this is what you guys mean when you say "flush the cache".

Bye,

    Paul K. Rodman 
    rodman@mfci.uucp
    __... ...__    _.. .   _._ ._ .____ __.. ._