Re: [hatari-devel] monotonic global cycle counter

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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