Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!ispd-newsserver!ism.isc.com!ico!scottw
From: scottw@ico.isc.com (Scott Wiesner)
Subject: Re: Bitfield instructions--a good idea?
Message-ID: <1991Apr24.194701.752@ico.isc.com>
Organization: Interactive Systems Corporation, Boulder, CO
References: <1991Apr24.173400.13397@zoo.toronto.edu>
Date: Wed, 24 Apr 1991 19:47:01 GMT

From article <1991Apr24.173400.13397@zoo.toronto.edu>, by henry@zoo.toronto.edu (Henry Spencer):
> In article <9104231527.AA09611@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>>>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's only a win if you are reading that word *repeatedly*.  This isn't
> too likely to be a major performance issue.  

Unfortunately, there's a bigger problem lurking here.  Most of the
"frame buffers" on PC's aren't really a frame buffer in the traditional
workstation sense.  Most don't map all their video memory into the
CPU's address space.  They usually map 64k, and use some I/O registers
to do bank switching.  Access of the same address may be looking at
different parts of video memory.

Also, things like EGA's and VGA's are even more complicated, with 4 planes
of memory being shadowed at the same address, with a I/O port selecting
which plane is of interest on a read, and another I/O port selecting
what action should be taken on a write.  (Actions include masking with 
a plane mask, a bit mask, 4 choices of rastrop, etc.)  You definately
don't want to be doing standard caching on one of these cards.

Scott Wiesner
Interactive Systems
X Development Group