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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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?


> > To track what happens between VBLs, use:
> > 	profile on
> > 	b VBL ! VBL
> > 	c
> > 	profile save vbl-profile.txt
> 
> 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.

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

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


	- Eero