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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 01/06/2015 19:52, Eero Tamminen a écrit :
> 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?

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.


Nicolas