Custom calling conventions

[Manu]

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
>>
>> <mailto:doob at me.com>> wrote:
>>
>>    On 2012-02-21 20:45, Manu wrote:
>>
>>        On 21 February 2012 20:12, Jacob Carlborg <doob at me.com
>>        <mailto:doob at me.com>
>>        <mailto:doob at me.com <mailto:doob at me.com>>> wrote:
>>
>>            On 2012-02-21 18:03, Manu wrote:
>>
>>                On 21 February 2012 16:59, Michel Fortin
>>        <michel.fortin at michelf.com <mailto:michel.fortin at michelf.**com<michel.fortin at michelf.com>
>> >
>>        <mailto:michel.fortin at michelf.**__com
>>
>>        <mailto:michel.fortin at michelf.**com <michel.fortin at michelf.com>>>
>>
>>                    I have some experience bridging Objective-C and D. I
>>        once
>>                built a
>>                    complete wrapper system for Objective-C objects,
>>        each object was
>>                    wrapped by a D one. It worked very well, but it
>>        generated so
>>                much
>>                    bloat that it became unusable as soon as I started
>>        defining
>>                enough
>>                    classes for it to be useful. See the D/Objective-C
>>        bridge:
>>        <http://michelf.com/projects/_**_____d-objc-bridge/<http://michelf.com/projects/______d-objc-bridge/>
>>        <http://michelf.com/projects/_**___d-objc-bridge/<http://michelf.com/projects/____d-objc-bridge/>
>> >
>>
>>        <http://michelf.com/projects/_**___d-objc-bridge/<http://michelf.com/projects/____d-objc-bridge/>
>>        <http://michelf.com/projects/_**_d-objc-bridge/<http://michelf.com/projects/__d-objc-bridge/>
>> >>
>>
>>        <http://michelf.com/projects/_**___d-objc-bridge/<http://michelf.com/projects/____d-objc-bridge/>
>>        <http://michelf.com/projects/_**_d-objc-bridge/<http://michelf.com/projects/__d-objc-bridge/>
>> >
>>        <http://michelf.com/projects/_**_d-objc-bridge/<http://michelf.com/projects/__d-objc-bridge/>
>>        <http://michelf.com/projects/**d-objc-bridge/<http://michelf.com/projects/d-objc-bridge/>
>> >>>>.
>>
>>
>>                What was the primary cause of the bloat? I can't imagine
>>        my proposal
>>                causing any more bloat than the explicit jni call (or
>>                equivalent) woudl
>>                have otherwise.
>>
>>
>>            Template bloat. Every call bridging D/Objective-C is made
>>        throw a
>>            series of templates. This is for making it possible (less
>>        verbose)
>>            to create bindings.
>>
>>            It might be possible to decrease the template bloat by
>>        having a tool
>>            that automatically generates the bindings and outputs what the
>>            templates do inline.
>>
>>
>>        Why aren't the templates inline themselves? Although if the
>>        templates do
>>        a lot of work, wouldn't that INCREASE the code volume?
>>        I can't really imagine how Obj-C linkage could bloat so much,
>>        what was
>>        involved? What did you have to do in addition to what a regular
>>        Obj-C
>>        function call would have done?
>>
>>
>>    Michel Fortin explained this better in two of his answers. You can
>>    also read the documentation of my implementation, very similar to
>>    Michel's:
>>
>>    http://www.dsource.org/__**projects/dstep/wiki/__**
>> ObjcBridge/BridgeInternals<http://www.dsource.org/__projects/dstep/wiki/__ObjcBridge/BridgeInternals>
>>
>>    <http://www.dsource.org/**projects/dstep/wiki/**
>> ObjcBridge/BridgeInternals<http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals>
>> >
>>
>>    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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120222/cfa80d0c/attachment.html>