Re: [hatari-devel] Issues with cache hits/misses?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 02/06/2015 22:14, Eero Tamminen a écrit :
Hi,

On tiistai 02 kesäkuu 2015, Nicolas Pomarède wrote:
Le 01/06/2015 19:52, Eero Tamminen a écrit :
On maanantai 01 kesäkuu 2015, Nicolas Pomarède wrote:
Le 01/06/2015 19:19, Eero Tamminen a écrit :
Thanks, your DTA fix is enough, I can add similar call to
other GEMDOS sites that write directly to memory (listing
files in TOS desktop works, but running programs doesn't yet).

There may also be other places where that needs to be done,
e.g. with debugger command to read file contents into memory...

I changed calls for do_put_mem_xxxx ; other places are often using
STMemory_WriteXXXX. So adding a call to flush cache just in this
function should be enough (that was my plan, but I forgot to do it
yesterday :) )

Why in one gemdos.c function you did Flush after memory operations
and in another before memory operations?

This doesn't really matter, in one case I thought it was more readable
to do it first in case we hit a 'return' earlier ; in the other case, I
did it at the end, since there was no way this part would be bypassed.

In all cases, what matters is that the code that intercepts the OS call
does both the correct mem writes and a cache flush, the order does not
matter.

Looking at the code, it seems that 030 cache in WinUAE is
writethrough.  flush_dcache() seems to just invalidate
cache lines, cache contents aren't written to emulated
RAM.

However, if WinUAE adds at some point 040 cache emulation,
that should support both writethrough and copyback modes.
With copyback cache, the order does matter.

Cache contents should first be flushed to system memory,
then emulator code can modify the emulated system memory.

Otherwise cache flush happening later could overwrite GEMDOS
modified memory contents with stale data from cache.

Cache should also be invalidated so that cached read from
updated memory area doesn't use stale data in cache.  For
invalidation it doesn't matter whether it's done before
or after system RAM update as that's atomic operation
from the emulated system point of view. :-)

I.e. for future proofness, cache flushing should happen first.



Yes, that's something that should be taken care of. But then, we will certainly need to come back to the code, as for now flush cache takes an address and a size in parameter, but in fact it flushes everything. This is not an issue for a small 256 bytes caches, but for a bigger one, we might need to have a better mechanism.





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/