Re: [hatari-devel] monotonic global cycle counter

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 12/08/2013 20:21, Eero Tamminen wrote:
> Hi,
>
> On maanantai 12 elokuu 2013, Nicolas Pomarède wrote:
> > I saw in atari-forum a note about the global cycle counter :
> >
> > "After Nicolas has had time to make the CPU cycle counter saner in
> > Hatari (monotonic 64-bit one starting at boot which works similarly on
> > all CPU core configurations), I can change several things in debugger to
> > use that instead of VBL and instruction counts"
> >
> > For me, CyclesGlobalClockCounter is already working for both old and new
> > cpu cores. It starts at 0 when Hatari starts and then it's always
> > increased (never reset during warm/cold reset).
> >
> > So, it should be good to use as a reference in statistics ?
>
> Nope.  Quoting from profilecpu.c:
> ------------------
> /* This is relevant with WinUAE CPU core:
>   * - the default cycle exact variant needs this define to be non-zero
>   * - non-cycle exact and MMU variants need this define to be 0
>   *   for cycle counts to make any sense
>   */
> #define USE_CYCLES_COUNTER 1
> ...
> #if USE_CYCLES_COUNTER
>          /* Confusingly, with DSP enabled, cycle counter is for this
>           * instruction, without DSP enabled, it's a monotonically
>           * increasing counter.
>           */
>          if (bDspEnabled) {
>                  cycles = Cycles_GetCounter(CYCLES_COUNTER_CPU);
>          } else {
>                  Uint32 newcycles = Cycles_GetCounter(CYCLES_COUNTER_CPU);
>                  cycles = newcycles - cpu_profile.prev_cycles;
>                  cpu_profile.prev_cycles = newcycles;
>          }
> #else
>          cycles = CurrentInstrCycles + nWaitStateCycles;
> #endif
> ------------------
>
> I.e. currently one needs *three* different ways to calculate cycles,
> not one.  Which way is needed depends on which CPU core is in use
> (new or old, cycle accurate or not, DSP enabled or not.
>
>
> 	- Eero

I will have a look at this ; the plan is to drop 
Cycles_GetCounter(CYCLES_COUNTER_CPU) anyway.

Having different cycles for different purposes (_VIDEO, _CPU, _SOUND) is 
not optimal in the end.
Each time cycles are changing, it required to update the 3 counters, 
whether they will be used immediatly or not.

It's better to have one global monotonic counter and let each HW 
component maintains its own copy (ie its local "clock") when it needs it.

Dropping CYCLES_COUNTER_VIDEO is more work, because it's used a lot, but 
dropping CYCLES_COUNTER_CPU should be possible without too much breakage.


Nicolas