Fwd: Re: [hatari-devel] Re: [hatari-users] DSP emulation - MPY #immediate

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Eero,

A mail from Doug and my answear.
I think we'll have to check this together.

Laurent



Hi Doug,

First, be very careful with the N,R and M registers in hatari, as on a real DSP, their value can only be used after 1 other instruction; but in hatari, their value change and can be used immediatly (I'll have to fix this one day).

Normally, you should have a compiler warning if you use the Nx value immediatly after seting it (I'm not so sure about it).


For the timings : it looks strange, as
> p:0050  21de00         (02 cyc)  move a,n6                                         0.01% (15153, 60612)

I indicate 2 cycles into the parenthesis (which seems to be well counted), but the profiler gives 4 cycles.


> Can you explain what is happening here? Is it just a profiler bug or something odd happening in the emulation core itself?

Good question, I check this from the DSP part.
Eero, can you check from the profiler part ? (I think we'll have to check this one together).

Laurent

-------- Message original --------

Sujet:	Re: [hatari-devel] Re: [hatari-users] DSP emulation - MPY #immediate
Date :	Mon, 28 Jan 2013 15:45:24 +0000
De :	Douglas Little <doug694@xxxxxxxxxxxxxx>
Pour :	laurent.sallafranque@xxxxxxx

Hi Laurent,

I have another question for you regarding DSP emulation / cycle counts / profiling.

p:004f  044e16         (04 cyc)  lua (r6)+n6,r6                                    0.01% (15153, 30306)

p:0050  21de00         (02 cyc)  move a,n6                                         0.01% (15153, 60612)

p:0051  21fa00         (02 cyc)  move b,n2                                         0.01% (15153, 30306)

In the above example, 'n6' is written shortly after it has been used, however the measured timing for this operation is 4 cycles (60612:cycle_sum / 15153:incidence_sum) and not the expected 2 cycles. This timing seems to correlate with the *previous* instruction. 

Another example:

p:0099  0aa981 000099  (06 cyc)  jclr #1,x:$ffe9,p:$0099                           0.01% (8813, 20062)

p:009b  576701         (02 cyc)  tfr b,a b,x:(r7)                                  0.00% (8204, 49224)

I see this occur in many other places, but not necessarily everywhere - e.g. divides *seem* to look sensible:

p:00bb  0618a0         (04 cyc)  rep #$18                                          0.07% (113102, 226204)

p:00bc  018040         (02 cyc)  div x0,a                                          1.56% (2714448, 5655100)

p:00bd  210500         (02 cyc)  move a0,x1                                        0.07% (113102, 226204)

Can you explain what is happening here? Is it just a profiler bug or something odd happening in the emulation core itself?

Thanks,

Doug.