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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 02/06/2015 23:33, Eero Tamminen a écrit :
> Hi,
>
> On tiistai 02 kesäkuu 2015, Nicolas Pomarède wrote:
> > Le 01/06/2015 19:34, Nicolas Pomarède a écrit :
> > > 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 :) )
> >
> > I changed STMemory_Write(), but other functions that do memcpy or
> > similar to the ST memory should be updated too.
>
> After some testing, there are at least some Falcon
> demos that worked earlier which don't work anymore:
> - yepyha
> - virtual city
>
> And Laurent's Beats of Rage freezes (with music playing on bg)
> to the score table at startup, so I think there may still
> be problems with cache.

Hi

that's strange, no freeze for me (falcon + CE cpu + 16 MHz + 14 MB RAM), 
the game works correctly.

> Places which use do_put_mem_* could potentially changed
> to STMemory_Write*:
>
> $ grep -l do_put_mem_ $(find src/ -type f|grep -v cpu/)
> src/includes/ioMem.h
> src/falcon/crossbar.c
> src/stMemory.c
> src/msa.c
> src/gemdos.c
> src/video.c
>
> stMemory.c has the wrappers so it can be ignored.
>
> ioMem.h wrappers can be ignored as IO-mem isn't cached, right?
>
> gemdos.c I've reviewed and all places using those functions do
> also other direct Atari memory access so changing them doesn't
> help, I've just commented them a bit more and moved flushing
> as first thing for consistency (same thing also in STMemory.c).
>
> Nicolas, can you look into rest C-files?


I already checked these files earlier in fact :
 - msa.c : no problem, it writes into buffer to build msa files, but 
not in ST's ram directly

 - ioMem.h : shouldn't be a problem, as IO region is not cachable

 - crossbar.c : do_put_mem_word are used through dma, so I don't think 
it would go through the cpu and the cache, it would access memory directly

Regarding msa.c, I think it is misleading to use do_put_mem_xxx (which 
is the low level access to memory in cpu emulation) for other things 
than accessing emulated memory.

When accessing some internal buffers, I think it would be better to have 
some other functions in utils.c for example ; even if the code would be 
the same as do_put_mem_xxx, that would help to separate functions that 
access RAM in the emulator space from those that access RAM in the 
emulated machine (so we wouldn't have to wonder if the call in msa.c 
need cache flushing or not)


> There are also places accessing STRam[] directly:
>
> $ grep -l STRam $(find src/ -type f|grep -v cpu/)
> src/includes/ioMem.h
> src/includes/stMemory.h
> src/debug/profilecpu.c
> src/falcon/crossbar.c
> src/falcon/videl.c
> src/hdc.c
> src/fdc.c
> src/tos.c
> src/stMemory.c
> src/dmaSnd.c
> src/memorySnapShot.c
> src/video.c
>
> Most of these are just reading STRam(), but some are also
> writing, those need also to be reviewed.

As above, if the access to STRam is the result of some DMA access, it 
should be safe (eg hdc.c, fdc.c)

tos.c : copies tos image into tos region before emulation starts, so 
shouldn't affect cache

stMemory.c : init memory before starting, so should be OK

memorySnaphot.c : just a comment

video.c : used for direct access to video memory

crossbar.c : dma sound, so should not affect cache

videl.c : seems only related to converting screen


Nicolas