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

[ Thread Index | Date Index | More Archives ]

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.

See my other posts, it's not related to VBL or video, for some reasons
it's the cache access / shift operation that shows this slowdown as if
the code was really not well optimised in that case. Really strange.

I don't see how this one line could use so much CPU that it
would make whole emulation 10x slower.  Especially without
it being visible in profiler and there being no slowdown
with Falcon/EmuTOS & TT/TOS3, just with TOS v4.

I don't see either :) But just try the lines I show in previous mail, and you will see that speed gets higher.

Note: TOS v3 is fast regardless of the TOS Desktop Cache setting.

Do you enable MMU with TOS v3 ? (I guess so, because it doesn't work without MMU IIRC). If so, the fact is that data cache is not emulated in MMU mode, so speed is not altered :)

Could the problem be related more to this line causing something
else to happen in the emulated TOS v4 m68k code?

No, this just returns the same value, so I don't see how it could change the emulated ST.


Mail converted by MHonArc 2.6.19+