Data cache hit/miss ratio analyser

[selco]

I found an interesting discussion and eventually understood how the data cache of the 68040/60 is working. (at least I think so ;-) https://stackoverflow.com/questions/...29152#48029152



There are also two gif animations showing which memory of an example program is cached.


Would it be difficult/possible to add some kind of cache analysis to the debugger?


My current idea would be
set a start and end breakpoint
when start reached, enable cache analysis (assume empty cache)
when end breakoint reached, stop cache analysis and read statistics. hits vs. miss ratio could be displayed.



Or is something like that already possible in winuae? Do we have statistics counters already?

[Locutus]

I think for this to be doable is for the exact cache behavior of the 040 and 060 to be documented, which i'm not sure it is.

[selco]

The goal would be for instance to find data that are really heavily used and are spread in "critical stride distances" over memory.

[mschulz]

Originally Posted by Locutus

I think for this to be doable is for the exact cache behavior of the 040 and 060 to be documented, which i'm not sure it is.

The cache behavior is pretty well documented. For example, 68040 Users Manual section 4.1 describes how everything is working including selection of cache line within a set which should be used next. So yeah, such statistics could be eventually implemented. Ofc not in case of real 68040 since it does not do such stats internally.

[selco]

Originally Posted by mschulz

Ofc not in case of real 68040 since it does not do such stats internally.

Sure. Thats why I was thinking the emulator could fill that gap.

[Toni Wilen]

Do you mean two counters, cache hits and misses? (separate counters for code and data) that some debugger command would reset/output?

But I am not sure if it returns any useful number(s) because part of test code might be (accidentally) already cached. Should cache counter reset command also (optionally) flush the cache?

Anything more complex would make emulation even more slower.

Cache emulation does what datasheets say but it can't be 100% perfect because order of instruction's internal memory operations are not defined.

[selco]

Originally Posted by Toni Wilen

Do you mean two counters, cache hits and misses? (separate counters for code and data) that some debugger command would reset/output?

Yes. We could run to a breakpoint before a very time consuming loop for instance. Then reset the counters, continue and run to a second breakpoint directly after this loop. Now sow the counters.

Originally Posted by Toni Wilen

But I am not sure if it returns any useful number(s) because part of test code might be (accidentally) already cached. Should cache counter reset command also (optionally) flush the cache?

I guess the cache misses at the begin of such a routine are unavoidable/impossible to predict. Bit in a heavily used routine that shouldn't have big impact to the ratio? But yes, flushing the caches seems to be a good idea go give more reproduceable rsults.


Ideally I would like to have some indication if/how I could for instance improve the data cache hit rate by reorganising/shrinking data structures, which code needs to be made smaller or needs to be moved to better fit into the instruction cache lines and wich opcodes cause pipeline stalls...


No idea if that really helps a developer but only WinUAE could provide such insights into the internals.