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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/