Technical Q&A HW28

DR Emulator Caches

Q: Our 68K application is crashing on Macs that have the new Dynamic Recompiling (DR) emulator. If we call FlushCodeCache() and FlushDataCache(), the crashes stop. Is this a bug in the DR emulator?

A: This is not a bug in the DR emulator. The DR emulator now has an instruction cache that need to be flushed, just like the 68020, 030, and 040.

DR emulator reports itself as being a 68020 processor, just like the old emulator, but it now has an instruction cache that is variable in size (instead of the fixed sized caches on the real processors). Some applications fail to flush the instruction cache either because they did not realize it had one, or their testing on real 680x0 processors showed that flushing the cache was not needed because the cache was naturally flushed by the amount of code going through it.

The fix to the crashing is to flush the cache. If you have code that conditionally flushes the cache, or you do anything that might leave the cache in an inconsistent state, unconditionally flush the cache.

When running on a PowerPC-based Macintosh in PPC or 68K mode, the best way to flush the instruction cache is to call FlushCodeCacheRange() since this will remove only the minimum necessary amount of code from the processor's or DR emulator's cache and will result in the most minimal speed loss. For flushing the data cache, simply call FlushDataCache(). The DR emulator does not have a data cache so you may not need to flush it, see if just using FlushCodeCacheRange() fixes the crashing.

However, you may need to flush both caches in PPC code if you are modifying code since the code is often treated as data and is therefore in the data cache so flushing only the instruction cache does no good (the instruction is stuck in the data cache). For this reason FlushInstructionCache() and FlushCodeCache() will flush the data cache on an 040 or PPC.

Before calling any of these calls (except FlushCodeCache()) make sure that you use TrapAvailable() to check for _HwPriv(0xA198). FlushCodeCache() does not depend on the _HwPriv trap, it depends on _CacheFlush, which must be implemented on any Mac that has a cache.

You should call FlushCodeCacheRange() if the _HwPriv trap is available. If it returns a hwParamErr (-502), or _HwPriv is not available, you will have to flush the entire cache by calling FlushCodeCache().

See Also:

• develop 23, "Balance of Power; Power Macintosh: The Next Generation"
• Technote HW06-Cache As Cache Can