Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!julius.cs.uiuc.edu!rouellet From: rouellet@crhc.uiuc.edu (Roland G. Ouellette) Newsgroups: comp.arch Subject: Re: Icache flushes, self-modifying code and multiprocessors Message-ID: Date: 19 Dec 90 06:32:08 GMT References: <1990Dec18.150615.26762@dg-rtp.dg.com> Sender: news@julius.cs.uiuc.edu (USENet News) Organization: University of Illinois Center for Reliable & High Performance Computing Lines: 43 In-Reply-To: hamilton@siberia.rtp.dg.com's message of 18 Dec 90 15:06:15 GMT I think we are almost in violent agreement... > When the code stream changes, it's necessary to cause all data caches in > an MP system to writeback, and then to invalidate all instruction caches Lets not say they need to writeback... The instruction cache will not be a writeback cache on any sensible system. The caches need to become coherent. Flushing them is sufficient. > (Harvard architecture, instruction caches don't snoop... Yes I agree. I missed the MP issue here, where different processors share the same instruction stream. > Life is somewhat easier on VAX and similar proprietary CISC > architectures, because there is much flexibility to move the > implementation from hardware to microcode to an OS trap handler while > preserving the user-level illusion of direct hardware support for the > desired functionality. But even there, I would expect that many > implementations would implement what appear to be user-level cache > control operations by trapping to kernel software or microcode, which > is not exactly direct hardware support. Actually the cache flush function is trival... it is one monster driver and a few gates per valid bit on the icache. There's no real need to trap to the OS, microcode, whatever ... at least for a VLSI cache tag store. > Surely the VAX REI instruction doesn't flush all instruction caches in a > multi-processor? No... I think that OS support might be appropriate here as there is processes shouldn't be locked onto specific processors (gang scheduling is fairly icky). With gang scheduling, just pingging your cooperating processes to flush their caches would be OK. Hmmm... that is interesting... I never thought of multiprocessor self-modifying code applications. -- = Roland G. Ouellette ouellette@tarkin.enet.dec.com = = 1203 E. Florida Ave rouellet@[dwarfs.]crhc.uiuc.edu = = Urbana, IL 61801 "You rescued me; I didn't want to be saved." = = - Cyndi Lauper =