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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

> What I *think* is meant here that it is not available for next instruction when calculating another EA. Simplified:

Finally, it seems more complicated than you and I thought :


test4:    ; start the test
    move    #$20,a
 
    do a,end_loop
    movem p:$0118,r0
    lua (r0)+,r1
    nop
    movem r1,p:$0118
    nop
end_loop
    wait_transmit
    move    p:$0118,a
    move    a,x:HTX


Here,     lua (r0)+,r1 calculates an EA

Tested on my real Falcon, I get $20 in the final HTX (also in the current hatari version).
But with my patch that takes into account a AGU pipeline EA, I should get 0.

It seems not to apply for all EA moves (or something I still don't understand well).

Any idea ?

Laurent





Le 22/12/2014 18:01, Laurent Sallafranque a écrit :

Hi,

Thanks a lot for the reply, this makes sense.
I've got an idea to fix this bug once for all.

But it'll be after the chrismas hollydays ;)

Laurent



Le 22/12/2014 09:04, Miro Kropáček a écrit :

On Mon, Dec 22, 2014 at 1:21 AM, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

Note: This instruction is considered to be a move-type instruction. Due to pipelining, the
new contents of the destination address register (R0–R7 or N0–N7) will not be available
for use during the following instruction (i.e., there is a single instruction cycle pipeline
delay).

What I *think* is meant here that it is not available for next instruction when calculating another EA. Simplified:

move a,n0

move n0,b

is perfectly legal while

move a,n0

move x:(r0+n0),b

is not.

So you're OK to write

lua (r0)+n0,n1

move n1,b ; updated n1 here

but not

lua (r0)+n0,n1

move x:(r1+n1),x0 ; using old n1 here

The pipelining problem is about EA calculation, not instruction ordering.

--

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