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