🚀 go-pugleaf

I added the comp.unix.* and biz.sco.general newsgroups to the crosspost
list, because I think that people there may be interested in this
article...

In article <1992Nov30.221021.16784@ringer.cs.utsa.edu> kjurena@lonestar.utsa.edu (Keith R. Jurena) writes:
>Once and for all!!!!!
>
>The DLC and SLC chips are out only for large volume dealers to upgrade their
>386 board stocks to 486 performance.  The DLC has a FPU so a 387 won't
                                       ^^^^^^^^^^^^^^^^^^
                                       WRONG!

The Cyrix 486DLC is pin-compatible to the 386DX, and does NOT include
an onboard FPU.  It supports the 486 instruction set and has a 1KB
internal cache (as opposed to no internal cache of the 386DX or 8KB
internal cache of the 486DX).  The internal cache is not enabled on
reset.  A motherboard designed specifically for the Cyrix chip will
have special BIOS options to automatically enable the cache during
boot.  If you simply plug in a 486DLC into a generic 386DX motherboard,
you won't have that BIOS feature and will need an external software to
enable the cache.

The 486SLC is pin compatible with the 386SX, and all other comments
about the 486DLC applies to the 486SLC.

Cyrix currently ships both of these chips to OEMs only for use on
motherboards specifically designed to take them.  Although they will
probably work on other motherboards you cannot expect to get any
support from Cyrix on these boards.

The Cyrix 486DLC/SLC internal cache, when enabled, will experience
cache coherency problems when a device performs DMA (such as floppy
and hard disk operations).  The can be worked around by configuring
the cache to perform an automatic flush when the HOLD pin is active
(the cache enabling BIOS/software must have an option to configure
the cache this way).  This does cause a degradation in performance,
but is still better than no cache at all.  Another alternative is to
modify the software that performs DMA to force a cache flush prior
to the DMA operation.  This is clearly not an option for most people
without source code for their application/drivers.

I suspect that the 486DLC/SLC may also have problems with motherboards
with an external cache, but I can't venture to say what these might
be.

I am running a system that's been upgraded from a 386DX/20 to the
Cyrix 486DLC.  I don't have BIOS support for the internal cache,
so I have to use external software to enable it.  Under DOS, I use
the m5.exe utility (I also have the simpler do_cache.exe and
no_cache.exe utilities, but they don't offer the same degree of
configurability as m5.exe).  I wrote a SVR3.2 UNIX device driver
(for SCO/ISC) that allows the cache to be enabled/disabled/configured.
I am testing this driver now and plan to post the sources and binaries
in the near future.  I am also planning to release a SVR4 version
soon.

As for performance of the 486DLC vs. 386DX...  If you don't enable the
internal cache, the performance gain from the 386DX to 486DLC is
negligible.  The cache can improve the performance anywhere from
nothing to 300%+.  The actual increase depends greatly upon the
application, since the cache size is so small.  If the application
is such that it causes good cache hits, then you will get the high
end of the improvement spectrum.

For example, I was testing my Cyrix cache UNIX driver on the Cyrix
486DLC running at 20MHz (no external cache) under SCO UNIX 3.2v4.0,
running two ad hoc user benchmarks of my own.  One of these is a simple
loop of 10 million integer additions.  This is a tight loop which
involves no UNIX system calls, therefore has good cache hit rate.  With
this benchmark, the improvement of enabling the Cyrix cache is dramatic
as follows:

Cyrix 486DLC @ 20MHz, Internal cache disabled:

    $ time ./ubench

    real    50.2
    user    49.3
    sys      0.3

Cyrix 486DLC @ 20MHz, Internal cache enabled (auto flush on HOLD):

    $ time ./ubench

    real    21.2
    user    20.9
    sys      0.3

All figures are in seconds.  In this case, the cache gave it an
improvement of approximately 236%.  

My other benchmark causes poor cache hits.  It is a loop of 500000 calls
to the UNIX system call getpid().  The results:

Cyrix 486DLC @ 20MHz, Internal cache disabled:

    $ time ./ubench

    real    2:14.8
    user      30.8
    sys     1:43.4

Cyrix 486DLC @ 20MHz, Internal cache enabled (auto flush on HOLD):

    $ time ./sbench

    real    2:11.1
    user      10.6
    sys     2:00.6

In this case, the improvement is only 5%.  Note that the cache caused
a dramatic reduction of time spent in the user program, but the cache
misses running in the kernel and back increased the system time.  The
total comes out about the same.

It is also interesting to note that SCO UNIX 3.2v4.0 seems to have a
much higher system call overhead than SCO UNIX 3.2v2.0.  The same
benchmark will yield a real time of around 1:40 under 3.2v2.0 on the
same system running the 486DLC without cache enabled.  For the
performance minded you might want to consider this before deciding to
"upgrade" to 3.2v4.0.

My conclusion about the 486DLC:  with the internal cache enabled,
you can get better performance than a 386DX.  How much better?  It
depends upon what you run.  Under UNIX, the improvement is likely
to be somewhat disappointing.

I wonder why Cyrix decided on a 1K cache size.  I have always
considered the Intel i486's 8K cache size to be inadequete.  1K?
C'mon Cyrix.  Surely cost is the only reason right?  I think a
486DLC with 64K of internal cache would have been very nice!

Comments are welcome...

-Ti
-- 
    ///  Ti Kan                vorsprung durch technik
   ///   AMB Research Laboratories, Sunnyvale, CA. USA
  ///    ti@amb.org
 //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti