Re: [hatari-devel] strange DSP behaviour?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi Doug,

Well spoted !
I've found the problem.

The dsp_macr_p_x1_y0_b is bugged.

these 32 macr instructions all work the same way :

macr _ p(lus) or m(inus) _ reg1 _ reg2 _ dest_reg (A or B)


There are 32 of them and only one was buggued (the case you gave me in example) ;)

If you have a look at the function : dsp_macr_p_x1_y0_b in dsp_src.c and you compare it with the previous or the next macr function, you'll see that the order of the instructions into the function is not the same (the rounding is done too early).

I'll fix it tonight.

Regards

PS: I've verified the other macr, they seem OK.
PS2: I'll also verify the mpyr tonight.

Laurent



----- Mail original -----
De: "Douglas Little" <doug694@xxxxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Lundi 14 Juillet 2014 18:46:44
Objet: [hatari-devel] strange DSP behaviour?




I noticed this strange effect on Sunday, probably one for LaurentS :-) 

MACR seems to be selectively rounding the accumulator - or not rounding - depending on the weather. Or possibly it is never rounding. 

The only external influence on MACR (and other rounding ops) are the global scaling bits and these just affect the constant used to perform rounding. The zeroing of the lower 24bits of the destination accumulator is unconditional - it should always occur. But it didn't happen in the example traced below? 





> dr 
A: A2: 00 A1: 0055fc A0: 00ffa6 
B: B2: 00 B1: 000fc0 B0: 000000 
X: X1: 002000 X0: 080000 
Y: Y1: 000000 Y0: 0055fc 
R0: ffeb N0: 0000 M0: ffff 
R1: 0000 N1: 29a2 M1: 0002 
R2: 0001 N2: 0fc6 M2: ffff 
R3: 004e N3: 0001 M3: ffff 
R4: 0000 N4: 006c M4: ffff 
R5: 29a9 N5: eafe M5: ffff 
R6: 151a N6: ffff M6: ffff 
R7: 49a2 N7: 2400 M7: ffff 
LA: 0093 LC: 0001 PC: 008f 
SR: 8050 OMR: 02 
SP: 05 SSH: 008a SSL: 8040 

> ds 
p:008f 4dc7eb (02 cyc) macr +x1,y0,b y:(r7)-n7,x1 

> dr 
A: A2: 00 A1: 0055fc A0: 00ffa6 
B: B2: 00 B1: 000fd5 B0: 7f0000 
X: X1: 225100 X0: 080000 
Y: Y1: 000000 Y0: 0055fc 
R0: ffeb N0: 0000 M0: ffff 
R1: 0000 N1: 29a2 M1: 0002 
R2: 0001 N2: 0fc6 M2: ffff 
R3: 004e N3: 0001 M3: ffff 
R4: 0000 N4: 006c M4: ffff 
R5: 29a9 N5: eafe M5: ffff 
R6: 151a N6: ffff M6: ffff 
R7: 25a2 N7: 2400 M7: ffff 
LA: 0093 LC: 0001 PC: 0090 
SR: 8050 OMR: 02 
SP: 05 SSH: 008a SSL: 8040 



I haven't had time to investigate this more closely but this was a direct c&p from the Hatari debugger and seems conclusive - something wrong? 




See the DSP user manual, page A-114 for a description of MACR behaviour and the zeroing of LSW after rounding. 

http://bitsavers.informatik.uni-stuttgart.de/pdf/motorola/56000/1990_DSP56000_DSP56001_Users_Manual.pdf 





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/