Jump to content

Moveq : Beware !


Recommended Posts

I've just started playing with the GPU, so apologies if this is well-known.


If you read the doc carefully, you'll see that MOVEQ writes the destination register in cycle 2, unlike most instructions for which this happens in cycle 3. This is cool, because code like this doesn't cause a pipeline stall, even though we use r1 just after writing it :

moveq        #1, r1
or         r1, r0

But this can be a trap too ! Remember this bug ?

13 Scoreboard failure on successive writes

Note - This bug applies to both Tom & Jerry.

Level 0 software

Description If two instructions write to the same register with no read references to it in between, and the

second of the two completes before the first, then the register can be left holding the result of

the first, which is now what the programmer would expect. This is because there is no scoreboard

protection against an instruction writing to a register that is currently flagged as invalid.

It was never envisaged that this situation would actually occur, but some programmers have

managed to contrive circumstances under which it can occur, particularly when debug code is

inserted, e.g.

load (r3),r2; get data value
moveq 3,r2; over-write with bebug value

This combination can have the appearance of the MOVEQ instruction not being executed, as

the load data is written into r2 after the quick immediate data.

Work-around Put an instruction dependent on the data between the two, e.g. an or r2,r2 between the

two instructions above.

At the first glance this seems to only affect long-latency instructions such as LOAD... but because of the behaviour of MOVEQ, the following code doesn't work reliably either !


xor         r1, r1
moveq       #1, r1

So beware when you use MOVEQ...

Link to comment
Share on other sites

Very interesting, it should be great to have a list of all GPU/DSP bugs.


Maybe I should include this bug as a warning or error into jas.


PD:about my assembler, I had to sort a bit the code, but macros are near to be suported, now you can define macros with/without parameters, but only zero parameters macros are expanded.

Link to comment
Share on other sites

Walk the mindfield! =)


I have had problems having combinations like:


moveq #1,Rn

addq #1,Rn


inserting a NOP between them gave ok result... (reading my commented devman).


So one should defenitely beware of the write score bug!...

Safest bet is to never use the data on the secound line but 2steps away... (depending on case).

but to use pipeline optimisation you need to know when the result is written back... ....its almost never easy...



---------Note though:

Instead of using the "or rn,rn" thing use:


cmpq #0,Rn !!!!!


since the or itself has a writeback... (which can cause trouble). the cmpq dont have a writeback and is hence faster.... (though it alters flags!)..

Link to comment
Share on other sites

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...