#147945 - kusma - Sun Dec 30, 2007 10:28 pm
according to http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html __sync_bool_compare_and_swap() is a gcc built-in for CAS-operations. But when I try to use this on devkitARM, I get an undefined reference to __sync_bool_compare_and_swap_4. This looks to me like an unimplemented function for ARM-gcc (since the function is forwarded to the _4-version behind my back), is this so or is this simply intel-specific?
Edit: Just for the record, I'm trying to write a simple mutex-lock for a queue on the GFX-FIFO DMA to avoid stalling the CPU while feeding the FIFO. (Yeah, NDS-stuff)
#147958 - chishm - Mon Dec 31, 2007 3:56 am
From the looks of that page, they are Intel specific functions. If you don't mind writing a small ASM stub, you could use the SWP or SWPB instructions. They are atomic memory exchange instructions, used like so:
This results in r0 = [r2] and [r2] = r1. The memory bus is locked for the entire time that the instruction takes place.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#147979 - kusma - Mon Dec 31, 2007 12:34 pm
I've been digging a bit further, and it seems like those functions are intended to be implemented for all architectures, but aren't yet.
Anyway, I wrote up some code using the SWP-instruction yesterday (like chishm suggested, thanks), and that should do the trick. I already wrote some ARM9-atomic-ints at work using SWP, and debugging and testing them was a quite tricky, so I wanted to avoid having to do that again. But, I guess since this is a simple lock, I guess it's a bit easier.
#148132 - Miked0801 - Wed Jan 02, 2008 7:57 pm
FYI, the assembler code for Swap is busted on the GBA. Perhaps so on the DS's ARM7 as well.
#148141 - Dwedit - Wed Jan 02, 2008 8:50 pm
I've used the swp and swpb instructions many times with no problems. I've heard rumors that Nintendo doesn't like use of that instruction though.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148143 - Miked0801 - Wed Jan 02, 2008 10:28 pm
According to the -ahem- docs, there are issues with that instruction.
#148144 - kusma - Wed Jan 02, 2008 10:36 pm
Miked0801 wrote: |
FYI, the assembler code for Swap is busted on the GBA. Perhaps so on the DS's ARM7 as well. |
As long as it works on the ARM9, I'm happy, since that's where I need it ATM. It would ofcourse be handy on the ARM7, but I'm not planning on using it there yet ;)
#148148 - Dwedit - Thu Jan 03, 2008 12:04 am
Miked0801 wrote: |
According to the -ahem- docs, there are issues with that instruction. |
[citation needed]
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148154 - Miked0801 - Thu Jan 03, 2008 1:37 am
I'd love to, but I like my job as well - go Nintendo.
In case you have the relevent docs, it's in the GBA programming cautions, section 11.
#148157 - Dwedit - Thu Jan 03, 2008 3:13 am
Apparently, Jaleco didn't get the memo. When they released a commercial version of PocketNES, they left the swp instructions in.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#148193 - tepples - Thu Jan 03, 2008 2:03 pm
Miked0801 wrote: |
According to the -ahem- docs, there are issues with that instruction. |
Likewise, there is a well-known defect with the Sega Genesis mainboard's handling of the MC68000 TAS (test and set) instruction. Like ARM7's SWP, TAS is a read-modify-write instruction intended as a multiprocessor synchronization primitive. A few games depended on this defect and would not run on a later revision of the Genesis mainboard that fixed the handling of atomic RMW instructions.
For all I know, the official docs say something to the effect: "Avoid using the SWP instruction. In future revisions of the AGB chipset, Nintendo reserves the right to goof it up the same way Sega did on the Mega Drive."
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.