Re: MIPS / targetOS strange behavior
- From: Jan Brittenson <tri-x@xxxxxxxxx>
- Date: Fri, 24 Mar 2006 19:49:34 -0800
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.
++sem->count;
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
compiler.
.
- References:
- MIPS / targetOS strange behavior
- From: tbroberg_nospam@xxxxxxxx
- MIPS / targetOS strange behavior
- Prev by Date: Re: Please Help : mpc555 in automotive control
- Next by Date: SH'boom - did I get it right?
- Previous by thread: Re: MIPS / targetOS strange behavior
- Next by thread: Phillips ARM LPC3180, low power floating point processor
- Index(es):
Relevant Pages
|