Re: [hatari-devel] Hatari data cache tests

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 23/06/2015 00:15, Eero Tamminen a écrit :
> Hi,
>
> On maanantai 22 kesäkuu 2015, Nicolas Pomarède wrote:
> > Le 22/06/2015 00:30, Nicolas Pomarède a écrit :
> > >          cycles = CyclesGlobalClockCounter - cpu_profile.prev_cycles;
> > >          cpu_profile.prev_cycles = CyclesGlobalClockCounter;
> > >          cycles <<= nCpuFreqShift;
> > >
> > > IIRC, that's some code I sent you, but i it could be wrong, I don't
> > > think the << is needed, else we don't keep consistancy with the traces
> > > from disasm.
> > >
> > > I will have a look at this and let you know.
> >
> > I removed the shift by nCpuFreqShift as it was not needed. This didn't
> > affect statistics percentage in the profiler, because all cycles were
> > multiplied by the same amount, but this didn't match the cycles reported
> > by "--trace cpu_disasm".
>
> If the emulation cycles are always counted with 8Mhz clock, wouldn't
> better fix been to add shift to cpu_disasm output?

Hi,

Nope, this would give worse results.
In the case of the 68020/30, cycles counts are closer to real HW when 
you divide them by 2 (because we use 16 MHz). For example, a NOP will 
take 2 cycles in most cases, which is OK if we shift >> 1 (else we get 4 
cycles which is not as good).

Also, if we shift back disasm output with <<, then it won't be good, 
because all cycles are >> before being added to nCyclesMainCounter and 
CyclesGlobalClockCounter, so values won't match anymore. And what really 
matters is the shifted value in CyclesGlobalClockCounter, because this 
is the reference that drives all other components (fdc, video, mfp, ...).

So, if a NOP internally increments CyclesGlobalClockCounter by 2, then 
we must show "2" in cpu_disasm traces and "2" in profiler for consistancy.

Nicolas