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

[Miro Kropáček <miro.kropacek@xxxxxxxxx>]

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