Cache disabling -- why a big deal?

[~XT6510300~Frank McGee~C23~L25~6326~]

In article <7831 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>Did Intel really forget to put a "don't cache" bit in the MMU page
>table entries?  Did they forget to bring this pin out to the rest of
>the hardware?  Or did the entire set of people designing 386
>motherboards ignore this pin?  Why are people in virtual memory Unix
>systems having to muck around swapping PALs to disable cache access for
>I/O addresses?  Autoconfig does this in software in my Sun system -- it
>sets don't-cache when mapping in I/O devices for the drivers.
>I realize that under MSDOS some sort of hardware hack would be necessary
>(since it doesn't use page tables), but under Unix you ought to be covered.
>John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu at toad.com

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.

-- 
Frank McGee, AT&T
Tier 3 Indirect Channel Sales Support
attmail!fmcgee