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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

OK, a third test :

test3:    ; start the test
    clr    b
    move    b,x1
    move    b,r0
    move    b,r1
    move    #$20,a
 
    do     a,end_loop_3
    move    x1,r0
    lua     (r0)+,r1
    nop
    move    r1,x1
    nop
end_loop_3
    wait_transmit
    move    x1,x:HTX
 
fintst3:    jmp fintst3


Real falcon
X1 = $10

Hatari : X1 = $20


This time, I just changed the p:$118 by X1 and the result changes in the falcon (so the lua doesn't work the same way in both cases).

This time, it seems to suffer a half pipeline effect  ;)

I'll try to make sense of this.

Of course, to let the DSP finish it's loop, I let the 68030 make a look of 50000 divs. So the DSP has plenty of time to make the test ;)

Laurent




Le 04/01/2015 23:35, Laurent Sallafranque a écrit :

- r0 is, in fact, used:

r0 = 0

1. iteration

r0 = 0

old_r0 +1 => r1

r1 = 1

2. iteration

r0 = 1

old_r0 + 1 => r1

r1 = 1

3. iteration

r0 = 2

old_r0 + 1 => r1

r1 = 2

... something like that?

Yes, but for the third iteration, if there was pipeline effect, I think that at the end of the movem, R0 = 1 and not 2 (as R1 in the second iteration = 1 and writes its value to p:$118)

> - you're using 2 program words, i.e. it could somehow (don't ask me how) slow down the whole process and r0 gets the right value. what if you replace movem with, say, move r2,r0?

Yes, great idea, I test immediatly (I'll use X1 to be sure there's no pipeline effect here ;)


Hard problem for now ;)

Regards

Laurent
 

Le 04/01/2015 23:14, Miro Kropáček a écrit :

Ah so, now I get it.

On real hardware, I get

r1 = 2
r2 = 1
r3 = 1

Yeah, this makes sense, as discussed before.

On real hardware, 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

Why don't you initialize r0 to some non-zero value, like $0100 for example?

 

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.

 Three things I could think of:

- you're using 2 program words, i.e. it could somehow (don't ask me how) slow down the whole process and r0 gets the right value. what if you replace movem with, say, move r2,r0?

- you're tinkering with 'do' loop -- there are some restrictions for end of the loop situations, perhaps worth checking, too

- r0 is, in fact, used:

r0 = 0

1. iteration

r0 = 0

old_r0 +1 => r1

r1 = 1

2. iteration

r0 = 1

old_r0 + 1 => r1

r1 = 1

3. iteration

r0 = 2

old_r0 + 1 => r1

r1 = 2

... something like that?

Just from the top of my head, I can be terribly wrong, as usual ;)

-- 

MiKRO / Mystic Bytes
http://mikro.atari.org