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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 16/12/2014 00:02, Eero Tamminen a écrit :

> I was able to go into 8Mhz with the other methods I described,
> it just didn't help with the zero cycles issue.

Back on this "0 cycle" case.

As already discussed, the 68030 has some more advanced bus handling and 
cache than the 68020 and can delay write for example.

What this means is that some instruction can overlap when they are 
executed in a specific order (and maybe from the cache) : for example a 
2nd instruction will start processing during the tail part of a 1st 
instruction.

So, let's take 3 instructions A, B and C that would take 12, 8 and 16 
cycles from the motorola doc.

You would expect the 3 of them to take 12+8+16 = 36 cycles, but if B can 
start during tail part of A and head part of C can start during tail 
part of B and we overlap 4 cycles in these cases, then we gain 8 cycles, 
so a total of 28 cycles.

Those 28 cycles must be respected, because that's really the time it 
would take on real HW. So, from there, we can consider that B took 4 
cycles (not 8) and C took 12 cycles (not 16).

If B was 4 cycles alone and overlapped with tail of A, then it would 
completely run in parallel, meaning the number of cycles is in fact 0 
when you look at the total time of the 3 instructions sequence.

So, unless you have some specific case were sequence of instructions 
really doesn't match the cycle as well as the tail/head computation as 
describe in MC68030 manual, I would say this is perfectly normal, 
there's nothing we can do.

0 cycle instruction are in fact fully paralleled instructions.

Nicolas