Re: [hatari-devel] DSP performance

[Adam Klobukowski <adamklobukowski@xxxxxxxxx>]

Just a thought: why not emulate a global ticks (with one cycle per tick for DSP and one cycle per two ticks for CPU) counter? Then CPU and DSP know exactly what cycle the're on and should they finish current instruction or not. Even proper bus emulation might come out of this one day.

AdamK

2015-07-01 9:38 GMT+02:00 <laurent.sallafranque@xxxxxxx>:

Hi,

No, that's the opposite ;)


I start to answear the second part of your question first :

> But even so, there might be a bug when dsp runs for 42 cycles instead of
the expected 48 ?


This is normal and expected. The 68030 and the DSP are independant.
The 68030 runs at 16 Mhz and the DSP at 32.

If a CPU instruction takes 10 cycles, the DSP must run for 20 cycles.

But if the DSP runs only 6 cycles instructions at this point, it will run for 6*3=18 cycles or 6*4=24 cycles (instead of 20 cycles expected).

That's why is dsp.c I added a while loop and a dspcycles variable (to count the dsp cycles eaten).
The 68030 increase this variable by 2 times the cycles of the current instruction, the DSP decrease it when it executes one instruction.
So, sometimes the DSP will execute a bit more cycles and sometimes a bit less cycles than the 68030.
But in average, they run at exactly 16 and 32 Mhz (if the CPU frequency is accurate of course).



The first point now :

> Forget it ... One x2 is to simulate a 32 MHz freq (twice the cpu) and
the other might be because the dsp can run 2 instructions per cycles ?

I don't think so. The DSP runs 1 instruction by one.
Of course, there's the 3 parallal pipeline that allow "3 instructions at once", but it's still counting as 1 instruction.

If a CPU instruction takes 20 cycles, the DSP cycles counting must take 40 cycles (+- a few cycles as described before)

If I remenber well my work in the "old" new CPU core, the cycle unit in cycle exact mode was computed like this (currcycle * 2 / CYCLE_UNIT)

I understood that "* 2 / CYCLE_UNIT" was the atomic cycles unit" but maybe I misundeerstood.
If I remeber well, everything used this value (* 2 / CYCLE_UNIT) so I had a good relation between DSP and CPU cycles.


For the "less exact mode", the atomic cycle unit was computed differently with a single variable (as far as I remenber) and there was not this *2

But again, from what I understand, I don't think the *2 is the problem, it was just the value of the atomic cycle.



I think that there's a real *2 problem now in hatari (at least in exact mode) as 1 CPU cycle seems to give 4 DSP cycles instead of 2.
I'll try to check tonight the other modes (prefetch mode and less accurate mode) for both new and old winuae CPU to compare.


Hope this makes sense to you, else ask me.

Laurent



----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Mercredi 1 Juillet 2015 00:42:46
Objet: Re: [hatari-devel] DSP performance

Le 01/07/2015 00:39, Nicolas Pomarède a écrit :

> Laurent, is there really a bug that used a x4 factor instead of x2, or
> am I missing sthg inth way dsp emulation runs ? And why 42 cycles are
> used instead of 48 ?

Forget it ... One x2 is to simulate a 32 MHz freq (twice the cpu) and
the other might be because the dsp can run 2 instructions per cycles ?

But even so, there might be a bug when dsp runs for 42 cycles instead of
the expected 48 ?

Nicolas

--

Semper Fidelis

Adam Klobukowski
adamklobukowski@xxxxxxxxx