Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!Postmaster From: johnl@iecc.cambridge.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: Bitfield instructions--a good idea? Message-ID: <9104231527.AA09611@iecc.cambridge.ma.us> Date: 23 Apr 91 19:27:16 GMT References: <1991Apr15.193425.3436@waikato.ac.nz> <1991Apr23.053619.13474@kithrup.COM> Sender: Postmaster@iecc.cambridge.ma.us Organization: I.E.C.C. Lines: 18 In-Reply-To: <1991Apr23.152155.2298@zoo.toronto.edu> In article <1991Apr23.152155.2298@zoo.toronto.edu> you write: >Anybody who caches a frame buffer is crazy. ... Given how slow some of the frame buffers on PC clones are, upwards of 10 wait states per 16 bit word, caching could be a big performance win. It should probably be write-through, though I can even imagine situations where you're redrawing an entire window and, so long as you can flush it when you're done, a little smudge during the repaint due to a write-back cache wouldn't be offensive. Recent models of screen buffer do remap all of the planes at the same place in the address space, which makes a lot of this moot unless you can do a page flush without a context switch. But even that's possible on the 386 -- it does let you enable individual device addresses for user I/O. Regards, John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl