|Re: [hatari-devel] Suspicious instruction & data cache hit/miss accounting|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 02/01/2018 12:36 AM, Nicolas Pomarède wrote:
[...]>> I.e. how/why most of instructions have *neither* cache hits or
Le 31/01/2018 à 23:22, Eero Tamminen a écrit :
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.
(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.