Custom calling conventions

[Jacob Carlborg]

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>
>         <mailto:michel.fortin at michelf.__com
>         <mailto: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/>>>>.
>
>
>                 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>
>
>     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.

-- 
/Jacob Carlborg