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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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.


	- Eero