Re: sync.m

[David Chisnall]

On 3 Mar 2010, at 19:20, Riccardo Mottola wrote:

> Hi,
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
>> 
>> In NSObject, we have a lot of code for doing atomic operations, to support 
>> old compilers, and we still don't have (for example) fast paths for SPARC, 
>> ARM, or MIPS unless you use GCC 4.2 or newer.  We only have fast paths on 
>> PowerPC and M68K because I wrote the former and worked with Riccardo to 
>> implement the latter.
>>   
> wow, so except the m68k thing that was done more for fun a weekend but is 
> perhaps not of such big interest (or does somebody runs gnustep on an 
> embedded platform?) Sparc, ARM and MIPS would be of wider use.
> 
> I can look and test Sparc and MIPS (LE). Maybe we can do that on another 
> rainy weekend, David? An excuse to dig out the sparc-asm.
> Actually, I think I did implement it for the Kaffe Java-VM, I should look 
> there.

If you're using Clang or GCC >= 4.2 then you get the fast path on these 
platforms with the compiler intrinsics.  It's only if you're using an older GCC 
that you have problems.  I'm not sure what your little MIPS machine uses, but 
I'd imagine it's a sufficiently recent GCC for this not to be an issue.  I 
think you said OpenBSD on SPARC32 is still using an ancient GCC, but it is 
supported by clang, so it would be worth switching on that platform.  

ARM gets a lot of attention from Apple at the moment (apparently they ship some 
things with ARM chips in them), so it has good support in clang and quite good 
support in recent GCC for EABI platforms, but not so much for OABI ones.  I 
think there might be some code in MySTEP for the atomic ops though, as I seem 
to recall Nikolaus using GCC 2.95 for a long time and performance on a 200MHz 
ARM chip using an objc_mutex for protecting reference counts would have been 
painful (unless he just didn't support multiple threads, in which case he could 
have used nonatomic ops).  

Actually, I wonder what kind of performance difference we'd see if we replaced 
-retain and -release with nonatomic versions and swizzled the methods to use 
the atomic versions when the will become multithreaded notification is posted.  
I might have a go at implementing that, if anyone has some good benchmarking 
code for testing it...

David

-- Sent from my IBM 1620