On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:
On 30 Mar 2009, at 16:37, David Chisnall wrote:
NSInvocation.m provides default implementations in terms of
__builtin_apply() and friends that are not used when libffi or
ffcall is provided. Is it possible to move these into a separate
concrete subclass of NSInvocation along the lines of
GSFFIInvocation/GSFFCallInvocation and only compile them when no
better mechanism is provided?
I should think that's not only possible, but a very good idea.
Great news.
I *think* (iirc) a little of the code in mframe is used for some
NSMethodSgnature features. It may be that we always need that part
compiled in, but it should be possible to separate out what we need,
and only build the rest of the code if we don't have libffi or ffcall.
Using the power of grep, I see:
NSMethodSignature uses some mframe stuff for parsing type encodings.
This doesn't really make sense being in mframe.m, since it's nothing
to do with creating call frames.
NSConnection uses them in -forwardForProxy:selector:argFrame:, which I
believe is deprecated since all of the argframe stuff was deprecated
years ago and never worked correctly, and in a few places with #ifdefs
so they're not actually compiled.
NSInvocation.m uses them in the fall-back code for when ffcall and
libffi are not present.
NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment().
The stuff for decoding type strings should probably be pulled into a
separate file.
objc-gnu2next.m uses them in a function that is deprecated on the
legacy Apple runtime and not supported by the modern Apple
runtime. Does anyone actually use next_objc_msg_sendv()?
I don't but it's always dangerous to assume that nobody else will.
On the other hand, that's old enough that we might insist on people
changing. The next major release will need to break ABI
compatibility for 64bit code in order to be compatible with Apple's
recent changes, so now is probably a good time to introduce other
cleanups that break the ABI in little-used or unused ways.
This function seems to be part of an attempt to reproduce the old NeXT
runtime API. More recently, I've been working on implementing the
ObjC 2.0 runtime API (supported by Apple for both their new and old
runtimes) on top of the GNU one. You can see the current version here:
http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/
At some point, I'd like to push this up to GNUstep[1] and have the
Apple runtime APIs properly supported. Now that Apple has deprecated
posing and defined a stable public API for the runtime, I would
imagine a lot of programs are going to start using it.
David
[1] If possible, I'd like to keep the MIT license for these files so
they can be easily used outside of GNUstep as well, since they are low-
level and have potential applications for Objective-C code that does
not use GNUstep.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev