Re: [hatari-devel] profiler cycles (was New WinUAE core issue with Bad Mood)

[Douglas Little <doug694@xxxxxxxxxxxxxx>]

It is possible for an opcode to take 0 real cycles on 68030, depending on how it is being 'measured'.

Most ops have a fixed execution time but they can overlap to a small degree with one another (a complete occlusion is rare) and with effective address calculation and memory writes.

But if you're seeing 0-cycle opcodes in bulk it is much more likely to be a bug :)

D

On 11 December 2014 at 22:51, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

On torstai 11 joulukuu 2014, Nicolas Pomarède wrote:
> can you try this quick and dirty patch ? I think it should fix the
> cycles counting in the profiler code.
>
> Basically, CyclesGlobalClockCounter is the 64 bit monotonic counter that
> get increased after each instruction and that can be considered as the
> "main" clock for the emulation (this counter is increased in m68000.h)

Thanks, it seems to fix the assert in profiler.

With profiler debugging enabled, I'm still getting
"Zero cycles for an opcode" warnings though,
for this kind of instructions:

$06b6ee : 3001  move.w    d1,d0   0.54% (14238, 0, 0)
$06b6f0 : 4840  swap      d0      0.54% (14238, 28856, 0)
$06b6f2 : 2208  move.l    a0,d1   0.54% (14238, 0, 0)
$0200ba : b280  cmp.l     d0,d1   0.27% (7139, 0, 0)
$01fee6 : 4a84  tst.l     d4      0.27% (7139, 0, 0)
$0200b4 : 588f  addq.l    #4,sp   0.27% (7139, 100, 0)
$0210fa : 6708  beq.s     $21104  0.27% (7100, 0, 0)
$0210fe : b082  cmp.l     d2,d0   0.27% (7100, 0, 0)
$021102 : 2400  move.l    d0,d2   0.27% (7100, 368, 0)

As you can see from above, some of them have never
gotten cycles, some have somethings (cycles is second
number in parenthesis).

This how larger piece of code around them can look like:

$06b6e6: 4c39 0401 000e 9ae4 mulu.l  $e9ae4,d0,d1 0.54% (14238, 228768, 0)
$06b6ee: 3001                move.w  d1,d0        0.54% (14238, 0, 0)
$06b6f0: 4840                swap    d0           0.54% (14238, 28856, 0)
$06b6f2: 2208                move.l  a0,d1        0.54% (14238, 0, 0)
$06b6f4: 4e75                rts                  0.54% (14238, 228296, 0)

Is it really possible that move.w and move.l above
don't consume any cycles?


> With this, it should be possible to remove the #if USE_CYCLES_COUNTER
> you added, as there's no more different behaviour depending on dsp
> yes/no or old/new cpu core.
>
> If you wish, you can update profilecpu.c this way if it works.


        - Eero