Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!cam-cl!news From: cet1@cl.cam.ac.uk (C.E. Thompson) Newsgroups: comp.arch Subject: Re: cache pre-load/no-load instructions Message-ID: <1991Mar24.151523.21921@cl.cam.ac.uk> Date: 24 Mar 91 15:15:23 GMT References: <765@ajpo.sei.cmu.edu> <1991Mar21.161044.2898@rice.edu> <27671@neptune.inf.ethz.ch> Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson) Organization: U of Cambridge Comp Lab, UK Lines: 29 In article <27671@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes: >In article <1991Mar21.161044.2898@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes: >>The RS/6000 includes 2 interesting possibilities. >>An instruction that zeroes a line in the data cache (without >>fetching it). May be used like (2 above); additionally handy for zeroing >>big chunks of memory. They also include an "invalidate line" >>instruction which says: "don't bother writing this one back to memory." >> > >Unfortunately, IBM made these instructions privileged. They had some good >reasons to do it, as the instructions ignore lock and protection bits. I do >not know the reasons why they could not make them check the bits, however. > Simplicity, I suppose: CLF (cache line flush) and DCLST (data cache line store) don't check either: but they don't have to, because they don't alter the relative consistency of cache and main memory. Even if DCLZ and CLI did check protection, you have to allow for scenarios such as the following. User program touches a never-before-referenced page in a work segment; kernel allocates a real page frame and zeros it with DCLZ instructions (this must be the archetypal use of DCLZ in practice). Now the user program must *not* be allowed to use CLI on this page, or it could read the previous contents of the real page frame which the kernel was trying to hide from it. Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk