[hatari-devel] Head cycles : x + op head

[Laurent Sallafranque]

Hi,

 > ... so I don't think it could be that cause of DSP/CPU sync problems.

Yes I agree. I don't want to be cycle exact accurate on Falcon, it's 
nearly not possible and it doesn't make sense as the 2 CPUs are working 
in parallel.
I'm just trying to be "as close as possible" to Falcon accuracy.

For now, all instructions cycles in the 68030 ce CPU from WinUae are 2 
cycles length. I think they've never finished this part of the code.
If I use the generic CPU, the cycles are 68000 ones.
As most demos and PRGs are running well with wrong timings, it means 
that very few programs are accurate timings dependant on Falcon.
But I think better timings will give better results.

For the DIV, I asked me the same question about the spread of the 
values. I'll try to check this from their program.
I've never seen min time information in the 68030 doc (which would be 
nice to have).

Nevermind, I'll start with the max values and adjust later to better 
values if necessary.

Regards

Laurent





Le 21/11/2011 12:05, Nicolas Pomarède a écrit :
> Le 21/11/2011 11:35, laurent.sallafranque at free.fr a écrit :
>
>> (DIV, MUL, ...).
>>
>> I've played around with gembench (they do a test with DIVU.W Dx, Dy 
>> repeated a lot of time).
>> Actually, I get 60% of the speed of a Falcon.
>>
>> I can use this test to "compute" an average value instead of the max 
>> value (which would be closer to reality).
>> The best would be to have the exact algo of the instruction to 
>> compute exact cycles (as it is done for the 68000), but nobody 
>> replied me (I asked in DHS forum).
>
> Hello
>
> regarding the mul/div algo, I already replied you : I think this 
> information is not available outside of Motorola and certainly covered 
> by patents. So I think it's quite unlikely we have access to it.
>
> Regarding doing an average of the times returned by gembench, the 
> problem is that you don't know how those values are spread and if 
> they're truly random. If they're not (for example if gembench does 
> 100000 div with always the same values), you can't use that, it would 
> not be an average.
>
> If you want to use an average value, I think it would be simpler to 
> use (min time) + ( max time - min time ) / 2  (using min/max values 
> from the motorola doc).
>
> But anyway, I don't think mul/div is a real problem. Apart from the 
> "ultimate" accuracy goal, I doubt many programs rely on exact timings 
> for these (on ST, it was only useful in protections with video sync 
> code). This value is variable also on Falcon, so I don't think it 
> could be that cause of DSP/CPU sync problems.
>
>
> Nicolas
>