Re: [hatari-devel] Hatari profiling question

[Toni Wilen <twilen@xxxxxxxxxx>]

> if you look at the code in newcpu.c, you can see that it's surrounded by
>
> #ifdef WINUAE_FOR_HATARI
>
> so it's code specific to hatari, not toni's code :)

Yeah.. Not sure what does numbers mean but..

> > > $00e21794 : adda.w    d2,a0       2.79% (1178064, 2361790, 1419, 0)
> > > $00e21796 : adda.w    d3,a1       2.79% (1178064, 2353471, 38, 0)
> > > $00e21798 : move.l    d1,d0       2.79% (1178064, 7068967, 1178050, 0)
> > > $00e2179a : move.w    (a0),d0     2.79% (1178064, 10689954, 190, 577010)
> > > $00e2179c : swap      d0          2.79% (1178064, 7069362, 1178150, 0)
> > > $00e2179e : move.l    d0,d1       2.79% (1178064, 76, 0, 0)
> > > $00e217a0 : rol.l     d4,d0       2.79% (1178064, 76, 0, 0)
> > > $00e217a2 : jmp       (a2)        2.79% (1178064, 14139013, 2356248, 0)
> > >
> > > Like I said, I'm not sure how to interpret the I-cache misses,
> > > particularly in the last line. Is it because it's a JMP and both the
> > > cache miss while fetching the instruction as well as the cache miss
> > > while fetching the jump target count towards the number? Or is it
> > > because the cache misses for the instruction *preceding* the JMP (ROL.L,
> > > shown with 0 I-cache misses) are counted towards the JMP instruction?

Assuming the question is about JMP causing many instruction cache 
misses: it can be normal because pipeline refill means 2 long reads 
(pipeline needs 3 words) and both can miss the cache and they happen 
during JMP execution (even if at least in theory pipeline refill after 
any branch is probably internally separate "instruction")

68020 and 68030 has long word sized holding register which is either 
loaded from instruction cache or from memory which means single word 
size instruction execution might not need any cache or memory read and 
prefetch can read opcodes for two following instructions.

Alignment of opcode also matters (long aligned vs only word aligned), 
for example jumping to non-long word aligned address would "waste" one 
word because prefetches are always long aligned long reads. (for example 
jump to $122 would cause prefetch from $120 and $124)

Cache hit/miss counts should be mostly accurate. Order of accesses might 
not be correct because no one knows how 68020/030 decides order of 
prefetches vs data if both are pending (CPU is still microcoded but bus 
sequencer and instruction execution run separately). Cycle timing is not 
very accurate.

Hope this helped.