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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 28 toukokuu 2015, Nicolas Pomarède wrote:
> Le 24/05/2015 23:56, Eero Tamminen a écrit :
> > It prints "run_2ce".
> > 
> > That's with following system settings:
> > - Falcon emulation
> > - 68030
> > - prefetch mode
> > - cycle exact
> > 
> > Same thing with "run_2p" i.e. "--cpu-exact no".
> 
> this should now be fixed. Memory regions needed to be defined as
> "cachable" in order to be used by the 68030 data cache (else cache was
> considered disabled, even if CACR was enabled).
> 
> Then a problem appeared in newcpu.c where data cache itself had a bug
> where returned values were not correct in case of a 'hit'.

Btw. If you want to build Hatari both with optimizations and
debug symbols, don't change CMakeLists.txt, instead use
"cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO".


> So, data cache will now work in 68030 when cycle exact mode is enabled.

Things don't work correctly with GEMDOS HD emulation:
- Name of the first file in a directory is shown for all files
- About every program I tried to run in TOS v4 gives error #35,
  probably for same reason

I can run programs from disk images though.

What GEMDOS HD emulation should do in presence of data cache, when
it modifies emulated memory (e.g. DTA) according to the requested
OS call?


> But note that this will be *very, very slow*. Managing the cache takes a
> lot of cpu

I profiled Hatari and compared how much DSP emulation cost changes
in relation to m68k emulation cost.  Based on that I calculated that
the 030 cache handling added 10-20% overhead (closer to 10%).

More interestingly, EmuTOS and TOS v3 seems to work at OK speed.

It's only TOS v4 that is really slow.  Either TOS v4 breaks with
data cache, or Hatari emulation (VBL timing?) doesn't work with
TOS v4.

Note: latest EmuTOS (0.9.4) release doesn't boot with TT/Falcon
emulation, you need newer EmuTOS snapshot, from here:
	http://sourceforge.net/projects/emutos/files/snapshots/


Btw. you can also run Hatari with "taskset 0x1" to bind it to a single
CPU core and turn off extra costs with "--sound off --dsp none" and
you'll see in "top" (after pressing "1") that there's plenty of CPU
free on the core on which Hatari runs.


> so maybe we should have an option to disable 68030 cache and
> keep it enabled only when people want to profile some code.

While emulation doesn't work with it as well as without, it's
better to disable data cache by default and have it enabled only
with some option saying "experimental" or "experts only"
(nothing in GUI).


	- Eero

PS. According to profiler, largest CPU data cache misses (14)
on idle GEM desktop come from code like this:
$00e094dc : 4cdf 7ffe                          movem.l   (sp)+,d1-d7/a0-a6
$00e094e0 : 3039 0000 1d0a                     move.w    $1d0a,d0

And largest data cache hits (>50) come from similar code.