Hi,
On 02/01/2018 12:36 AM, Nicolas Pomarède wrote:
Le 31/01/2018 à 23:22, Eero Tamminen a écrit :
[...]>> I.e. how/why most of instructions have *neither* cache hits or
misses?
Based on our WinUAE code, it seems that instruction cache hits & misses
aren't counted for pipelined instructions, only for instructions
requiring cache fill, either because there's a branch or prefetch.
While accounting can be fixed later e.g. to mark anything not causing
misses as having a hit, I wonder whether the miss stats are correct.
Any comments?
(And as you can see, some of the executed instructions can incur
multiple i-cache hits or misses.)
I'm not sure why same happens for data cache. I think hits & misses
are skipped in the CPU emulation core only if data cache is disabled.
However, above case is EmuTOS idling in TOS desktop. I don't think
it would be toggling data cache on & off...
Would it be possible that largest part of memory accesses are done
through accessors that actually don't go through data cache checks?
it could be that I forgot to count hit/miss in some places.
Do you have a way to run the same test by customising your traces
output to show disasm + hit/miss counters after each instruction ?
This way we could see when counters are not incremented which would
give a hint on where values where not counted.
The cpu can also makes a difference as they use different cache
system. I guess it 68030 ?
After you enable profiling ("profile on"):
* "profile caches" command shows then the overall statistics for
all executed instructions since emulation was last continued.
* disassembly shows in addition to instruction counts & cycles,
the i-cache misses and d-cache hit counts, accumulated for
each instruction address.
Cache info is based on the CpuInstruction.(I|D)_Cache_(hit|miss)
counters provided by the CPU core. Profiling code zeroes
them after each executed instruction.