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 :