[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: GNUstep 2.6.0 for openSUSE 11.4

From: David Chisnall
Subject: Re: ANN: GNUstep 2.6.0 for openSUSE 11.4
Date: Wed, 15 Jun 2011 09:39:34 +0100

On 14 Jun 2011, at 23:19, Nat! wrote:

> Am 14.06.2011 um 23:47 schrieb David Chisnall:
>> On 14 Jun 2011, at 22:38, Nat! wrote:
>>> Hmm interesting, though I don't see offhand, why dividing  what 
>>> objc_msgSend does  into separate steps makes it inherently more portable. I 
>>> will have to look into my code, to see if its feasible to roll my own 
>>> objc_msgSend, (because I use it a lot as I found out :) ).
>> objc_msgSend() is a trampoline function.  It must pass all of its arguments 
>> to the called IMP.  This is not possible in C.  Apple implements a version 
>> of it in assembly for every calling convention, for every architecture, and 
>> for every platform that they support (currently, this comes to about a dozen 
>> implementations, and they support a very narrow range of platforms compared 
>> to GNUstep).
> Ah I see. I hope, that if I reduce the scope to a small fixed number of id 
> parameters, I can get by. 

It's really better to just call class_getMethodImplementation() and call the 
returning IMP.  This code will work everywhere, and the performance difference 
between using it and using objc_msgSend() is tiny.

Note that you are supposed to cast objc_msgSend() to the correct type before 
use anyway (95% of the time, this doesn't matter, 5% it will corrupt your 
stack), and you need to make sure that you call the _sret, _fpret suffix 
versions (not all of which exist on all Darwin targets) to call it correctly.  
objc_msgSend() is designed for compilers to use, not for you to use.  The logic 
required to select the correct one is nontrivial, to say the least.

>>> Ah and one more question, regarding forwarding is __objc_msg_forward 
>>> (instead of __objc_msg_forward2) ever really used or can I ignore it, when 
>>> I run atop a current runtime ?
>> The forwarding hooks that are used depend on the runtime. See 
>> GSFFIInvocation.m for how they are all used.  
> Is there some exported #define (like OBJC_API_VERSION) that could be checked, 
> which runtime I am compiling against ? 

Not really.  GCC 4.6 and later define something.  The GNUstep Runtime defines 
__GNUSTEP_RUNTIME__ in objc/runtime.h and then provides a set of capability 
flags in objc/caps.h to let you check at compile time and run time which 
capabilities the runtime that you are using supports.

>> You should never need to care about any of them in your own code.
> Hmm, maybe it is different on GNUstep. On OSX I know that I care :)

On OS X, these forwarding hooks are not even part of the semi-public API.  You 
can only find them by digging around in the libobjc source.  They also have a 
habit of changing without notice and without backwards compatibility.  If you 
are using them on OS X, then you are definitely doing something wrong.  The 
only reasons that they are part of the 'public' API with GNU libobjc 
implementations is that they are part of the libobjc<->Foundation interface, 
and we don't have the luxury of tying libobjc to Foundation quite as closely as 
Apple does.

With the GNUstep runtime, all hooks like this are declared and documented in 
objc/hooks.h.  If you're including this file outside of a compiler or a 
Foundation implementation, then you are almost certainly doing something very, 
very wrong.


-- Sent from my Difference Engine

reply via email to

[Prev in Thread] Current Thread [Next in Thread]