Re: [hatari-devel] DSP bug: need more explanations

 LOL, it's quite complicate I think. I've done 2 tests : TEST 1   test1:    ; start the test     clr    a     move    #\$1,r0     move    a,r1     move    a,r2     move    a,r3     nop     nop     lua    (r0)+,r1     lua    (r1)+,r2     lua    (r2)+,r3       wait_transmit     move    r1,x:HTX       wait_transmit     move    r2,x:HTX       wait_transmit     move    r3,x:HTX On real hardware, I get r1 = 2 r2 = 1 r3 = 1 On hatari current version, I get r1 = 2 r2 = 3 r3 = 4 Which means that    lua (r1)+,r2    and   lua (r2)+,r3    suffers the pipeline effect TEST 2 test2:    ; start the test  (p:\$118 = 0)     move    #\$20,a       do a,end_loop     movem p:\$0118,r0     lua (r0)+,r1                                 ; R0 is unchanged by the lua     nop     movem r1,p:\$0118     nop end_loop     wait_transmit     move    p:\$0118,a     move    a,x:HTX On real hardware, I get : a = \$20 OnHatari, I get : a = \$20 From my point of view : After the first loop, R0 = 0 and p:\$118 = 1 At the beginning of the 2nd loop : r0 goes from 0 to 1 (the value in p:\$118) , but may suffers the pipeline effect So, the next lua (r0)+,r1 should take R0 = 0 and R1 = 1 The final result with a pipeline effect should be 1, not 20 Which means that the   lua (r0)+,r1  doesn't suffer the pipeline effect in this case. The same instruction suffers the pipeline effect in test 1 and not in test 4 In both case, it's a EA move. I'm a bit lost here ;) Laurent Le 04/01/2015 11:00, Miro Kropáček a écrit : On Sat, Jan 3, 2015 at 8:01 PM, Laurent Sallafranque wrote:     movem p:\$0118,r0     lua (r0)+,r1 I'm sorry, I lost you here :) So what do you expect to happen? What are initial values of r0 and p:\$0118? -- MiKRO / Mystic Bytes http://mikro.atari.org

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