Re: MIPS / targetOS strange behavior

tbroberg_nospam@xxxxxxxx wrote:
In this snippet from a semaphore post routine, sem->count is -1 before
execution and 0 after, but the wrong branch is taken about once a week
if it feels like it.

lw v0, 20(s3) ; s3 contains a pointer to the semaphore
struct, offset 20 is the count within the semaphore
addiu v0, v0, 1 ; Increment count
sw v0, 20(s3) ; Write count out to semaphore structure

if ((savedSemCount = sem->count) <= 0)
lw v0, 20(s3) ; Load count v0 again (Why didn't the compiler
optimize this out?)
bgtz v0, *+212 ; Branch if semaphore count now positive

Is anybody aware of any cases where the processor itself might muck
this up and load the wrong v

Try disassembling the binary to check that the delay slot
between store/load is actually filled, and that there is
no (broken) reordering.

I assume sem->count is declared volatile, and this is why
you get an explicit reload for each reference.

Are you using gcc w/gas? Gas automatically fills delay slots,
and gcc got a bunch of delay slot changes in 4.0.1. Either
way, check the actual output, not just .s files produced by the