Cache controllers, can Xenix use them? -- Xenix yes others no

[Steve Dyer]

In article <1581 at eneevax.UUCP> jsrobin at eneevax.eng.umd.edu (John S. Robinson) writes:
>	In each case it	usually took several days and many call backs, but in
>	the end I was able to determine that only SCO would 'claim' that they
>	supported the 82385 cache controller. I suspect that this is one of the
>	prime reasons that it is taking SCO so dreadfully long to get there
>	upgrade to Sys V 3.2 shipped, long after everyone else is shipping 
>	product.

The only reason I can imagine why SCO isn't shipping UNIX V 3.2 yet is
because they have to provide an environment which is compatible with
their earlier releases.  Microport (rip?), Interactive and AT&T could
essentially start from a "blank slate" of 386 customers or those who
are already familiar with System V.3 on other architectures.  SCO cares
enough to worry about all its customers running its earlier releases
who will be adding new machines and upgrading older ones.  UNIX V/386
3.2 out of the box just won't hack it alone--binary compatibility is
only a small part of keeping an operation running which already has
staff trained on the way SCO XENIX has been administered and has been
used.  Their 2.3 release is a transitional move towards complete
integration.

The stuff about "programming around" the cache controller in the other
flavors of UNIX sounds pretty spurious to me.  I would be VERY surprised
if CPU-bound programs compiled on either a XENIX 386 box or a 386/ix box
or an AT&T 3.2 box (choose one) showed different execution times on
identical machines with cache (with only the OS differing.)  Sounds easy
to test, though.

-- 
Steve Dyer
dyer at ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer at arktouros.mit.edu