Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Bitfield instructions--a good idea? Message-ID: <3361@crdos1.crd.ge.COM> Date: 23 Apr 91 17:46:14 GMT References: <1991Apr15.193425.3436@waikato.ac.nz> <1991Apr23.053619.13474@kithrup.COM> <1991Apr23.152155.2298@zoo.toronto.edu> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 28 In article <1991Apr23.152155.2298@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: | Anybody who caches a frame buffer is crazy. Especially if the cache isn't | write-through, in which case your frame-buffer updates show up on the screen | some arbitrary time later! The second part of this is true, but in a system which writes data to the bus aggressively, the arbitrary time is in ms, not seconds or minutes. Write-back cache seems to fall into the group which trys to unload the bus by only writing to memory when the cache is getting full, and the aggressive cache which writes whenever the bus is not busy. I played with caching a frame buffer, and it had a positive effect on performance, since calculation and writing of points was overlapped. Obviously a bank selected frame buffer can't (easily) be cached, but other than that I don't see any reason why cache won't work nicely. I don't think a write-through cache would make sense because *most* programs don't read back the buffer. I agree with the conclusion, that caching a frame buffer is not cost effective in most applications, but I'm not quite as firmly set against it as Henry. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"