Zerosquare Posted September 26, 2006 Report Share Posted September 26, 2006 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 More sharing options...
swapd0 Posted September 27, 2006 Report Share Posted September 27, 2006 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 More sharing options...
Fredifredo Posted September 28, 2006 Report Share Posted September 28, 2006 Swapd0 > Sebrmv aka "Macroboy" could help you ! Link to comment Share on other sites More sharing options...
Symmetry of TNG Posted September 28, 2006 Report Share Posted September 28, 2006 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 More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now