Re: [hatari-devel] Adding cache support for the MegaSTE

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 12/07/2024 à 17:49, Christian Zietz a écrit :
> Nicolas Pomarède schrieb:
>
> > from the result it means that we have cache hit when reading
> > (total=$df). This is slower than 3rd test ($a7) but that's because we
> > have 16384 writes instead of 8192 writes.
>
> One problem with interpreting these numbers is that you have to consider 
> that your code is also uncached or cached, depending on the machine 
> config. Hence, if you do, e.g., ...
>
> loop:
> MOVE.W (A0)+,D0
> DBF D1,loop
>
> ... you'll have some memory accesses for code (that are cached for sure 
> when the cache is on) and just one memory access for data, which is what 
> you are actually testing for.
>
> To distinguish between these situations, I suggest that you enhance your 
> program: In one test, you invalidate the cache and read memory that you 
> didn't write before. This will give you the number when you have cache 
> hits for code and cache misses for data. In a second test, you 
> invalidate the cache, write data and read it back. This will give you 
> the results with cache hits for code *and* data.
>
> (Actually, because of the cache topology, even in the second test your 
> code will replace a few words of data in the cache, causing some misses.)

I agree with your remarks ; also when using the VBL and HBL int to 
measure the elapsed time, this will push data on the stack at each 
interrupt and replace some data in the cache, hence causing some cache 
misses in the 16KB region that is supposed to be fully cached.

In my tests, code should never be cached, because I'm doing a cache 
flush before each test (code is only cached at start when TOS loads the 
PRG and write it to RAM) :

 - cache flush
 - write 16 KB in cache
 - read 16 KB from cache

Or do you mean data are cached when doing a read from memory too (which 
would cache code too) ? In the case of the megaSTE cache I thought that 
only writes to memory would update the cache.

but all in all it doesn't really matter if I have 5% misses or so and 
not 100% cache hits, I will still get the global picture of  Hatari 
having correct cache timings or not after reading 16 KB (in the sense of 
Hatari being 20% too fast or too slow when cache is used if I dont' 
count the correct number of cycles for a cache hit instead of the usual 
4 cycles par word access)

Nicolas