Xref: utzoo comp.sys.amiga.programmer:4077 comp.sys.amiga.hardware:9675
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!unixg.ubc.ca!brazeau.ucs.ualberta.ca!alberta!aunro!ukma!rex!spool.mu.edu!decwrl!sun-barr!rutgers!cbmvax!mks
From: mks@cbmvax.commodore.com (Michael Sinz)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware,adsp.sw,adsp.hw
Subject: 68040 Compatibility Warning
Summary: Issues on dealing with copyback caches in the 68040 and AmigaOS 2.0
Message-ID: <22049@cbmvax.commodore.com>
Date: 30 May 91 18:48:15 GMT
Reply-To: mks@cbmvax.commodore.com (Michael Sinz)
Organization: Commodore, West Chester, PA
Lines: 119


           *** 68040 CPU Compatibility Warning ***


Now that the 68040 CPU is available, it will not be long before
it is available on the Amiga. In fact, in many Amiga magazines
there are already ads for 68040 CPU cards.

With the 68040, you get a much faster and more powerful CPU.  It
has 4K of cache memory for instructions and another 4K for data.
The reason these are two separate caches is so that the CPU core
can access data while it is accessing instructions.  (That is, it
can do both *at the same time*)

Just the fact that the caches are so much larger can give
software that loads and then runs code some problems.  However,
this is not the worst case.  The 68040 data cache has a mode that
makes the machine run *much* faster in most cases.  It is called
CopyBack. CopyBack means that when a program writes data to
memory, it goes into the cache but *not* into the physical RAM.
That means that if something was to read that RAM and it did not
go through the data cache on the 68040, it will see old data.
The two main examples of this are DMA devices and the instruction
reading of the CPU itself.  This means that even if the
instruction cache is cleared, if you write to memory and then try
to execute that code it may not be in physical RAM yet and the
instruction read from RAM will be the stale data.

Simply put:  If you have the CPU store instructions into memory
that you wish to execute later, you *must* clear the caches if
you wish to work with 68040 caching modes.

AmigaOS 2.0 correctly clears the caches as needed after it does
the LoadSeg() of a program.  Applications need to do the same if
they create code at run-time.  One such example was the article
on multiple processes in AmigaMail.  What is needed is that just
before the call to CreateProc() that a call to the EXEC V37
CacheClearU() function is executed.  In C that would be:


extern struct ExecBase *SysBase;
:
:
:
/* We have just created a fake seglist and wish to start it */
/* If we are in 2.0, call CacheClearU() before CreateProc() */
if (SysBase->LibNode.lib_Version >= 37) CacheClearU();

/* Now do the CreateProc() call... */
proc=CreateProc(... /* whatever your call is like */ ...);
:
:
:



For those of you programming in assembly:
*
*******************************************************************************
*
* Check to see if we are running in V37 ROM or better.  If so,
* we want to call CacheClearU() to make sure we are safe on future
* hardware such as the 68040.  This section of code assumes that
* a6 points at ExecBase.  a0/a1/d0/d1 are trashed in CacheClearU()
*
		cmpi.w	#37,LIB_VERSION(a6)	; Check if exec is >= V37
		bcs.s	TooOld			; If less than V37, too old...
		jsr	_LVOCacheClearU(a6)	; Clear the cache...
TooOld:
*
*******************************************************************************
*



The above will keep the code working pre-2.0 but will do the
correct operations in 2.0.  Note that while this would mean that
your code could not work on a 68040 without the final 2.0
release, it is not much of a concern since pre-2.0 versions of
the OS could not correctly run with the 68040 and will not work
if the 68040 caches are turned on in CopyBack mode.

Note that CreateProc() is not the only time this could be a
problem. Whenever you create code (or load code) that is not 100%
done only via LoadSeg() you will need to call CacheClearU().
Many input.device handlers have been known to allocate and copy
up the handler code and then exit back to the system.  These
programs also need to have this call in them.

The other major case that can cause problems is with DMA devices.
Since DMA devices read/write data to memory directly, caches need
to be flushed as needed.  For example, if a DMA device was about
to read RAM via DMA, it would need to call CachePreDMA() to make
sure that caches have written to memory and that all is safe.

If a DMA device is about to write to memory, it should call
CachePreDMA() *before* the write, to make sure that no cache data
is still left to be written to RAM, then do the DMA, and finally
call CachePostDMA().

In addition, CachePreDMA() and CachePostDMA() gives the OS the
chance to tell the DMA device that the physical addresses and
memory sizes are not the same.  While currently this can not
happen, the future may bring such things as virtual memory and
thus it would be needed.  See the autodocs for more information
on these calls.


			-- Michael Sinz
			   Operating Systems Development Group
			   Commodore-Amiga, Inc.

/----------------------------------------------------------------------\
|      /// Michael Sinz  -  Amiga Software Engineer                    |
|     ///                   Operating System Development Group         |
|    ///   BIX:  msinz      UUNET:  rutgers!cbmvax!mks                 |
|\\\///                                                                |
| \XX/     Quantum Physics:  The Dreams that Stuff is made of.         |
\----------------------------------------------------------------------/