Cache disabling -- why a big deal?

[John Richardson]

In article <2944 at cuuxb.ATT.COM>, fmcgee at cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~L25~6326~) writes:
> In article <7831 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>
> About cache problems and shared memory boards....
> 
> I'm not an expert on the 82385, but I believe that it may be the case
> that it doesn't know that some areas of memory shouldn't be cached.  On
> the 6386/25 and 6386/33 (machines that AT&T announced Monday), the
> cache is implemented in discrete logic so that it only caches address
> space that is really occupied by RAM.  Basically, it doesn't cache any
> address space that isn't in a 32-bit slot (ie, it's in an AT or XT
> expansion slot, and is memory on some sort of expansion card).  That
> way you don't have to re-write your drivers if your card has dual
> ported RAM.
> 
  The INTEL 80385 cache controlller does not know about what should be
or what should not be cached. It has an input pin called NC for NO CACHE
that is valid for the current cycle to the cache controller chip. It is 
up to external logic to drive this pin. A recommendataion has been to use
A31. Most motherboards (all?) will always decode and not cache 640K to 1MEG.
The A31 convention will work for UNIX, but OS/2 will be a problem. Even 
though you can set A31 without paging by using the 80386 segment base
extention byte (the highest of the 8 byte descriptor), I do not remember
from the last OS/2 driver that I wrote if the current non-386 OS/2 allows
you to set this byte. (Short of reading the GDT register to find out where
it is, and find your selector in it and set it yourself!)

SIGH!

(there are undocumented OS/2 DEVHLP's that allow you to permenantly allocate
  GDT entrys for your driver)

					JR