31–40 of 41 posts
To quote the API documentation on Constructing Function Calls: "Using [built-in functions], you can record the arguments a function received, and call another function with the same arguments, without knowing the number or types of the arguments." [1]
[1] http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html
Ok, maybe I'm missing something, I'm not C nor Objective-C dev but... Language is just a specification, right? Which is just a document. Then you have to implement that language using that spec: interpreter, compiler, VM, runtime, whatever. So I was always under impression that you could implement any language in any other language (almost; sometimes with the help of another, more low-level lang, say assembly, C etc.…
I think what you are missing is that while any Turing complete system can solve the same problems as any other, not all programming languages have the same functionality. An easy example is that some languages are typed and some are untyped. Some have objects (Objective C) and some don't (C). Can you replicate the functionality of Objective C in C. Apparently not completely.
Earlier quoted context omitted.
There's no inline caching is there though? And so no 'mother of all optimisations' inlining. Or is my understanding of how Objective C works mistaken? You wouldn't dream of implementing a dynamic language these days designed for performance without basic polymorphic inline caching. But Objective C seems to get by fine without it. Maybe it's not as essential as we think.
There’s no inlining, because determining whether inlining wpuld be safe is probably Turing-complete. However, IMP cacheing is a thing and that’s enough for most cases. For the rest there is C and (Objective-)C++.
> Objective-C under the hood compiles every method call into a call to the function objc_msgSend(). Well, kinda. You need a family of functions (objc_msgSend, of course, but also objc_msgSend_stret, objc_msgSendSuper, and objc_msgSendSuper_stret), to get this to really work for when you have structures as your return value or are calling a superclass's implementation (or both!). Since the inline assembly that is objc…
This is also why dynamic languages like PyObjC, RubyObjC, RubyCocoa, MacRuby, Nu, and F# had difficulty bridging certain functions and methods, because you have to either create an insanely complex function that's able to take any @encoding and turn it into a runtime type, or you have to shimmy it with guesses for the most common ones like NSRect et al.
While the objc_msgSend, objc_msgSend_stret, et. al, is an annoying detail, that isn't really the hard part. (And in fact, all the good bridges use libffi to do more direct invocations and avoids a lot of this problem.)
The hard part of bridging is those places where Objective-C introspection is not powerful enough to discover the types of parameters or signatures of functions. Typically, this is all the C stuff.
So for example, Obj-C's runtime introspection cannot tell you the make up of a struct. So it cannot tell you the size of NSRect, NSPoint, NSSize, or the individual data types inside the struct (and the names of each item if you need to access them).
And the Obj-C runtime introspection cannot tell you about what C functions exist and what the parameter types and return types are. So for example, there is no Obj-C runtime way to look up that CGPointMake takes two CGFloat parameters and returns a CGPoint struct.
Also, inline functions (marcos) in C/Obj-C are also problematic for these bridges since they need to call the functions at runtime.
Apple shipped a framework called BridgeSupport in Mac OS X 10.5 which contains XML data for all the things that cannot be determined at runtime. It also contains .dylibs with symbols for inline functions. BridgeSupport is still in macOS today, but it isn't getting much love and Apple keeps (accidentally?) breaking things in BridgeSupport every release.
[object method: args...]
IMP tmp = objc_msg_lookup(object, @selector(method:))
*tmp(object, @selector(method:), args...)Earlier quoted context omitted.
> at compile time That's the key thing - other languages which solve this solve it dynamically.
Yeah, that’s what a JIT does. Unfortunately that’s not something that Apple really wants to open the door to on their platforms, especially for native code.
> Objective-C under the hood compiles every method call into a call to the function objc_msgSend(). Well, kinda. You need a family of functions (objc_msgSend, of course, but also objc_msgSend_stret, objc_msgSendSuper, and objc_msgSendSuper_stret), to get this to really work for when you have structures as your return value or are calling a superclass's implementation (or both!). Since the inline assembly that is objc…
When you think about it it's bonkers that this language is doing dynamic method calls without any inline caching and I presume no inlining ?!. You would think this was intractable for good performance, but it seems to work fine!
Also, Objective-C being “C with a little bit of dynamism where you need it” doesn’t need it as much as languages where every call is, principally, a dynamic one.
Having said that, the current implementation does some caching, but inside objc_msgSend, not inline with the call (https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-bui...)
Earlier quoted context omitted.
Yeah, that’s what a JIT does. Unfortunately that’s not something that Apple really wants to open the door to on their platforms, especially for native code.
I don’t think that comes into play here. Objective-C is C , and although you could JIT any language, C isn’t made for it, both philosophically (one of its main claims to fame is ‘close to the metal’) and technically (a source file cold be compiled multiple times with different macro definitions or with a different set of #included files)
Earlier quoted context omitted.
I don’t think that comes into play here. Objective-C is C , and although you could JIT any language, C isn’t made for it, both philosophically (one of its main claims to fame is ‘close to the metal’) and technically (a source file cold be compiled multiple times with different macro definitions or with a different set of #included files)
C isn't made for JIT because it's static; that's why inclining exists. Objective-C has room to improve because it has dynamic function calls.