Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!emory!gatech!mcnc!rti!dg-rtp!siberia!hamilton From: hamilton@siberia.rtp.dg.com (Eric Hamilton) Newsgroups: comp.arch Subject: Re: [m88200] cache flushes [on DG Aviion] Message-ID: <1990Dec17.154858.2300@dg-rtp.dg.com> Date: 17 Dec 90 15:48:58 GMT References: <1990Dec15.143354.8493@ux1.cso.uiuc.edu> <11421@pt.cs.cmu.edu> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hamilton@siberia.rtp.dg.com (Eric Hamilton) Organization: Data General Corporation, Research Triangle Park, NC Lines: 42 In article <11421@pt.cs.cmu.edu>, af@spice.cs.cmu.edu (Alessandro Forin) writes: |> |> I was told on the IBM 6000 box there are instructions to flush (ranges of?) |> the cache at the user level. |> Seems to me this shows there is no inherent compelling architectural reason |> why RISC architectures should not provide a good cache interface to |> their users (both OS and applications) if they create the need for one. |> |> A system call is not a "good" cache interface. No matter how many standard |> commitee members you put on top of it. |> Well, a system call *is* an instruction, albeit a very slow one, as far as the user-visible program architecture is concerned. The reason for requiring OS assistance/interference (pick one, according to your prejudices) in user cache operations is multi-processor systems. Direct hardware support for cache invalidate and writeback commands in an MP system is possible, but constrains and complicates the hardware design immensely. Think about how hardware might implement cache writeback/invalidate operations in an MP system.... When multiple processors initiate cache operations at the same time.... When each processor has its own data and instruction caches.... When the initiating processor cannot be allowed to proceed until all other processors have completed their writeback/invalidate.... Any reasonable implementation is going to require some system software involvement. The problem is somewhat similar to flushing the address translation cache after changing a page mapping, and OS designers have been using barrier synchronization for that purpose for years. What you should expect (and demand - this is an active thread in comp.sys.m88k) is that the system call that does the cache manipulation be very fast. You ought to be able to think of it as costing more like to a trap to emulate an unimplemented instruction than as a full-blown system call. Of course, if a substantial amount of the instruction cache must be invalidated or we have to wait for a substantial amount of the data cache to writeback, then the overhead for starting the cache operation will be the least of your problems. I'm not going to get involved in the "Resolved: Standards are Harmful" debate. Suffice it to say that the user cache interface is neither more nor less amenable/vulnerable to standardization than the rest of the user visible architecture. If you are in a standard-sensitive environment then you have to deal with a standards committee; if you aren't, you don't.