From jws Fri Aug 17 14:24 MDT 1990
Received: by hpfclw.HP.COM; Fri, 17 Aug 90 14:24:34 mdt
Date: Fri, 17 Aug 90 14:24:34 mdt
From: John Schmidt <jws>
Full-Name: John Schmidt
To: jwh@hpfclw
Subject: Copyback info
Status: RO

>From dew Fri Aug 17 14:13 MDT 1990
Received: by hpfclw.HP.COM; Fri, 17 Aug 90 14:13:32 mdt
Date: Fri, 17 Aug 90 14:13:32 mdt
>From: Dave Willis <dew>
Full-Name: Dave Willis
To: jws@hpfclw, markm@hpdcdb
Subject: 040 Cache Problem (REALLY)
Status: R


Mark,

Here is a write up of the 68040 cache problem, and methods of getting
around it.  As was mentioned yesterday, you may be a canditate to run
into this problem on the 68040.

Dave Willis
========================================================================
NOTES ON 68040 CACHING PROBLEMS -- JOHN MARVIN (8/8)

Problem Description
-------------------

    New generation HP 9000 Series 300/400 workstations will be using the
Motorola MC68040 microprocessor.  Almost all current Series 300
applications should run unmodified on the new generation workstations.
However, there are a very small class of applications that will break on
the new work-stations.

    The problem is due to the new copyback cache capability of the
MC68040.  With copyback caching enabled, performance in most cases is
greatly increased over the write-through caching case.  Therefore, to be
competitive, copyback caching must be enabled by default.  In most cases
copyback caching is transparent to the application.  The only problem is
when machine language is written at run time into the data cache and then
an attempt is made to execute it.  The problem is due to the fact that the
machine language will be sitting in the data cache, which is not searched
on an instruction fetch.



The Solutions
-------------

    There are two solutions to this problem, one requiring a modification
to the application (and therefore requiring access to the source).  One
solution is to specify the use of writeback caching for the data and/or
stack segment on a per program basis.  The other solution is to push dirty
cache lines out to main memory after the machine language has been written
to the data segment, but before execution of the machine language is
attempted.  The following sections will explain these two solutions in
detail.


Converting to Write-Through Caching
-----------------------------------

    The chatr(1) command has been modified for the 7.05 release to allow
an executable to be flagged so that HP-UX will use writeback caching for
the data and/or stack segment.  Chatr(1) allows the user to specify
writeback caching for the data segment, the stack segment, or both.
Chatr(1) can also be used to check on the current caching specification
for the executable.  In the next major release, ld(1) will also be
modified to allow the user to specify writeback caching at the time the
executable is created.

    In most cases, only the data segment needs to use writeback caching
for applications that write machine code as data and then execute it.  The
stack segment should not be made writeback unless necessary, since the
application could still benefit from the performance of copyback caching
for the stack.

    This solution is the only one available to users who do not have the
source in order to implement the cache pushing solution.  It is possible
that this solution may not work for some applications if they were not
written correctly for the 68020 or 68030 microprocessors.  There will
not be a problem if code that is written into the data segment for
execution is not overwritten later with new code. If the code is
overwritten, then the old code may be found in the instruction cache
when an attempt is made to execute the new code. This problem also
existed on the 68020 and 68030 microprocessors; however, due to the
small size of their instruction caches (256 bytes), it is possible that
applications never ran into this problem. The instruction cache on
the 68040 is 4096 bytes, so an application is more likely to run into
a problem if it did not purge the instruction cache. The only correct
way an application could have purged the instruction cache before the
7.05 release would have been to call the undocumented m68020_advise()
system call (which is now obsoleted by the more powerful cachectl()
call). Some third party developers were informed about the m68020_advise()
system call, and they may have incorporated it into their product.


Cache Pushing
-------------

    A new C library routine, cachectl(3C), will be provided in the 7.05
release to allow the user to push the data cache after the machine
language has been written to the data and/or stack segment, but before the
code is executed.  This method, in most cases, will provide better
performance for the application, since it will still be able to use
copyback caching.  Since cache flushing involves a privileged instruction
on the MC68040 processor, cachectl(3C) must make a call to the kernel in
order to do the flush.  This does involve a certain amount of overhead,
although every effort has been made to minimize the overhead involved in
calling cachectl().


Conclusion
----------


    In order to get the best performance, applications that write machine
code into the data segment and then execute it should be modified to use
cachectl(3C) to do selective cache management. Some applications, if they
did not overwrite instructions in the data cache, or if they used the
undocumented m68020_advise() system call, will run correctly if the
data segment caching mode is changed to writethrough via the chatr(1)
command. However, these applications would also benefit if they are
modified to use cachectl(3C).



