Cache controllers, can Xenix use them?

[was-John McMillan]

Probably the best advice on this topic was to read a recent [PC-mag., Byte?]
article on this particular cache.  I did, and I DIDN'T re-submit
clarifications.  SBC's note suggests some are needed.  (I'll also
point out that I believe I stated up front that I was NOT addressing
THIS cache directly as I hadn't seen the spec's on it.)

In article <422 at brian386.UUCP> news at brian386.UUCP (Wm. Brian McCane) writes:
>In article <1425 at mtunb.ATT.COM> jcm at mtunb.UUCP (was-John McMillan) writes:
>>	Caches usually require kernel software for:
>>	1) Boot-time checkout (validation);
   Nothing in the article indicated any validation is performed.

>>	2) Defective cache shutdown/workaround;
   Nothing in the article indicated any shutdown mechanism is available.

>>	3) Context-switch flushing;
   This cache is placed between Mem Manager and Phys Mem: it looks at
   Phys Memory only.  (Placing an cache where it reads Virtual Memory
   addresses is probably a pretty stupid thought on my part.)

>>	4) Memory-mapped hardware cache-BLOCKING;
   Nothing in the article indicated any mechanism is provided to permit
   memory-mapped hardware addresses.  This would be gross.  More information
   is needed.

>>	5) DMA-overlapped page flushing/blocking;
   One of this caches features is that it monitors the Physical Mem Address
   lines and disqualifies any entries it contains for DMA-addressed memory.

>>	6) Text-loading cache-flushing (split text & data caching);
   (Ref: (3) above.  This point is irrelevant if physical memory is cached.)
...
>Cache checking should be done in the power up routines just like the
>keyboard.  And if it is defective, the system probably won't boot,
>since I believe cache off on most systems means it doesn't cache, instead
>it just passes the data blindly.

  Some systems can run with their cache disabled.  AT&T has even
  distributed benchmarks of their machines where they'd forgotten
  to enable the cache: ouch!  (Generates some embarrassingly low
  throughput numbers.)

jc mcmillan	-- att!mtunb!jcm