Re: [hatari-devel] Suspicious instruction & data cache hit/miss accounting

[ Thread Index | Date Index | More Archives ]

Le 01/02/2018 à 00:19, Eero Tamminen a écrit :

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.

If you enable these during the test you did with idle tos, do you get any disasm traces that would tell some example of instructions / addresses which were not correctly counted in cache access ?

Mail converted by MHonArc 2.6.19+