Custom calling conventions

Michel Fortin michel.fortin at michelf.com
Tue Feb 21 20:38:08 PST 2012


On 2012-02-21 23:13:31 +0000, Manu <turkeyman at gmail.com> said:

> 
> On 21 February 2012 23:06, Jacob Carlborg <doob at me.com> wrote:
> 
>> On 2012-02-21 22:01, Manu wrote:
>> 
>>> On 21 February 2012 22:35, Jacob Carlborg <doob at me.com
>>>> But to give a quick example:
>>>> 
>>>> class Foo : NSObject
>>>> {
>>>> Foo foo ()
>>>> {
>>>> return invokeObjcSelf!(Foo, "foo");
>>>> }
>>>> 
>>>> Foo bar ()
>>>> {
>>>> return invokeObjcSelf!(Foo, "bar");
>>>> }
>>>> }
>>>> 
>>>> "invokeObjcSelf" is a template function that calls an Objective-C
>>>> method. Basically each time "invokeObjcSelf" is called a new
>>>> instantiation of the template is created and that is put in the
>>>> symbol table. "invokeObjcSelf" then calls several more template
>>>> functions making the template bloat increase exponentially.
>>> 
>>> But they should all be inlined, and the symbol table should be stripped,
>>> which shouldn't leave anything in the end other than the inlined
>>> function calling code, and in my examples, this will be basically the
>>> exact same code that you'd have to write anyway to call through some
>>> vm's API...
>> 
>> Well, that's not what happen with templates.
> 
> ... really? why?
> You've just made me very very scared for my simd module :/
> 
> I've had a serious concern about D's lack of a force-inline for quite a
> while...

I'm not sure what Jacob is referring to.

But here's what I can tell: Foo's methods can't be stripped because 
they're referenced by the virtual table. invokeObjcSelf could be 
inlined in theory, but it probably isn't because it is not that small 
considering it actually does exception bridging and argument/return 
value conversions as needed. Also, for each method there's also a 
trampoline function generated (by a mixin which is not in his example) 
which is referenced by the corresponding Objective-C reverse wrapper 
class (which is added dynamically on demand), so the Objective-C side 
can call the D method if you subclass the D wrapper and override one of 
its methods.

The problem is that if you write bindings for a significant part of 
Cocoa, you end up with thousands of those functions, and none can be 
stripped because they're all referenced somehow because they're needed 
for dynamic dispatch. Sure, you could inline what is inside the virtual 
function (invokeObjcSelf), but beside saving a few function prologues I 
don't expect it'll have a very noticeable effect. Even if you saved 25% 
of the symbols it won't bring things to a reasonable size or a 
reasonable compilation time.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list