Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: GVP 68030 reviewed in Sentry
Message-ID: <7083@cbmvax.UUCP>
Date: 12 Jun 89 03:10:14 GMT
References: <11044@mcdphx.phx.mcd.mot.com>
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 80

in article <11044@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) says:
> Keywords: Cache
> Summary: More Cache warnings

>    Unfortunately, I have been known to load a program or two in my usage of
> my Amiga.  If the program is transfered using DMA, there is a possibility
> of stale data in the instruction cache.  

In practice, this never happens.  The process of loading new code is enough to
overwrite the instruction cache, and _probably_, but not at all certainly,
the data cache (which is why we don't recommend running DMA and data cache
unless the device driver for the DMA hardware flushes the cache).

> The 68030 cache is not exactly a Most Recently Used cache, 

Well, yes and no.  The caches on both '030 and '020 are straight mapped 256
byte caches.  They're organized a bit differently, the '030 caches are both
16 entries of 4 longword lines, I don't recall the exact organization of
the '020 cache.  Minimally, though, in either case you overwrite a cache
entry by accessing an item on the same (address % 256) location.  So if you
wanted to make sure a data item wasn't cached, you could read that location
plus 256 (assuming that location's cachable), and you're guaranteed you won't
take a cache hit at your original location.  For instruction code, you'll
absolutely know you're not getting stale instructions if you've run code at
256 consecutive locations (no more that 128 instructions), or the equivalent,
before running your newly loaded code.  It's actually even less that that,
because the '030 doesn't deal with individual words, it invalidates in terms
of cache lines.  So in best case, you can completely overwrite the instruction
cache in 16 properly placed instructions (each entry in a cache line has the
same cache tag address, but can be independently validated.  When you change
the tag address by caching one longword, the other three are invalidated).

Note that this is all very '020/'030 specific; the '040, or either '020/'030
with external cache, will no doubt behave very differently.  You'll likely
have more obvious cache support in the OS by then, though...

>some stale data can exist even after thousands of instructions have been 
>executed (though not likely [read infrequent guru]).

That could happen, I suppose, but you'd almost have to design the example
yourself, and you'd have to be pretty clever about locating your code as
well.  You'd certainly have to avoid using the OS LoadSeg() call, the use 
of which appears guaranteed to overwrite the '030 cache.

>    I seem to recall a flush cache system call, but I could not find it in
> about 2 minutes of looking.  

Nope, none was required for '020 support (instruction cache only), which is
as far as 1.2/1.3 took cache support.  

> If it does not exist, it needs to (can you say 1.4 wish?  I knew you could.) 

I agree.

> It perhaps should be implemented as something external to the system 
> (Romtags?), so as new processors become available it can be easily changed
> (Also changable for aftermarket cache boards should they become available.)

Well it's only one function, I'd think.  I suppose a future OS would provide
an Exec call that knows how to flush the cache on machines it understands.
If you added a new CPU (like perhaps an '040) or new external hardware (an
external cache on an '030 possibly), you'd provide a driver for that board,
perhaps even automatically bound via the BindDrivers facility, that would
SetFunction() the required cache calls and at the same time enable the unknown
cache(s).
> 
>    Any task that is in control of DMA (say, the trackdisk device) would call
> this routine after the DMA is finished.  The routine would flush the cache
> if it exists.

Yup.  

> |    // GOATS - Gladly Offering All Their Support  Dave Kinzer (602)897-3085|
> |   //  >> In Hell you need 4Mb to Multitask!  <<  uunet!mcdphx!teroach!dbk |
> | \X/   #define policy_maker(name) (name->salary > 3 * dave.salary)         |

-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession