Re: [hatari-devel] Issues with cache hits/misses?

Sorry if I replied to the same stuff as you a few times - usually done in a hurry without catching up fully.

Movem should be the instruction with the maximum possible cache access, with up to 16 long words being read, this means a possible max of 32 d-cache accesses, so printing a warning for value above 5 or 6 will certainly print too much useless warnings.

Each d-cache entry is a single longword, so for 16 aligned longs thats 16 hits (or misses). If misaligned it would mean an extra one at the edge (if not in burst mode - otherwise it will likely be up to 3 more).

The 16-bit side of things doubles the number of actual fetches needed from the bus but the cache knows nothing of that. The bus interface handles the splitting. The cache only deals with 32bit fields, or groups of 4x32bit in burstmode.

The MMU part of the 68030 should be the same for Amiga and Falcon, but timings of the MMU are not really described in docs, so the cycles when applying translations and going throught 1 of the 3 possible levels of translation could be incomplete at the moment (that's what Tony told me if I recall correctly)
This could explain some differences between Hatari and real Falcon.

I attempted some timings for MMU and for both instruction and data fetches the MMU overhead appears completely transparent (free!), for up 2-3 levels of table. Don't know what happens beyond that.

There may be strange corner cases which add a cycle or two but I don't remember anything like that showing up.

However if there is an ATC miss, I have no idea what sort of overhead is involved. It's difficult to measure. Could be a lot.

On TOS I don't think it matters much though since the tables are too sparse and pages too large to count significant misses... it probably is more of an issue with MiNT etc...