[xplc-general] C binding implementations

[lionel petit]

Hi,

I'm thinking of what is the best way to implement components in C with the
least overhead than possible.
I read on the Avery's advogato page
(http://advogato.org/person/apenwarr/diary.html?start=35) that a successful
try was made in making dangerous assumptions on the vtable layout in C++.
It's the solution I have found before reading its paper... I know the vtable
layout is compiler dependant and, for some of them, you have to add some
padding to adjust the vtable. Despite this unpleasant padding, this solution
is very interesting because there is as much overhead as in C++!
What's your opinion on this and do you suggest other solutions? I would not
like to use an intermediate binary format and have some generation of code at
execution or create bridges which redirect all calls to the component.

Regards,

[Pierre Phaneuf]

Post by lionel petit
I read on the Avery's advogato page
(http://advogato.org/person/apenwarr/diary.html?start=35) that a
successful try was made in making dangerous assumptions on the vtable
layout in C++. It's the solution I have found before reading its
paper... I know the vtable layout is compiler dependant and, for some
of them, you have to add some padding to adjust the vtable. Despite
this unpleasant padding, this solution is very interesting because
there is as much overhead as in C++! What's your opinion on this and
do you suggest other solutions? I would not like to use an
intermediate binary format and have some generation of code at
execution or create bridges which redirect all calls to the
component.

Ah, but Avery had underestimated my cunningness at the time... I had
replied to him in another Advogato post, but due to some disk problems,
my Advogato account is gone. Oops.

The trick is, I just declared that XPLC enforces a vtable layout. It
just so happens that I picked the same vtable layout that COM uses.
Which also happens to be the vtable layout that every compiler either
converged to, or have an attribute to use it for a particular class (and
it's descendants). So you can just assume COM vtable layout safely.

I basically let Microsoft do what they're good at, twisting arms (of the
compiler vendors, in this case). Thank you, Microsoft! :-)

Which compilers did you have to use different padding, by the way?

If you want to know more about all the details of making these things
work, the COM Specification is very interesting.

There *is* a platform dependent part that will need to be built
eventually, which is a foreign function call layer, so that we can build
stack frames and call into interfaces (so that we can call into any XPLC
interfaces from scripting languages), as well as provide a proxy
interface that will disassemble it's stack frames (so that scripting
languages can implement XPLC interfaces). This layer could be shared by
any scripting language binding. See Mozilla's xptcall:

http://www.mozilla.org/scriptable/xptcall-faq.html

[Avery Pennarun]

Post by Pierre Phaneuf
There *is* a platform dependent part that will need to be built
eventually, which is a foreign function call layer, so that we can build
stack frames and call into interfaces (so that we can call into any XPLC
interfaces from scripting languages), as well as provide a proxy
interface that will disassemble it's stack frames (so that scripting
languages can implement XPLC interfaces). This layer could be shared by
http://www.mozilla.org/scriptable/xptcall-faq.html

My xplcidl actually implements this in a different way, avoiding the
horrible pain of manipulating stack frames and other stuff... but
potentially with a performance penalty. (Hey, you're in a scripting
language, how much worse can it be?)

Have fun,

Avery

[Pierre Phaneuf]

Post by Avery Pennarun
My xplcidl actually implements this in a different way, avoiding the
horrible pain of manipulating stack frames and other stuff... but
potentially with a performance penalty. (Hey, you're in a scripting
language, how much worse can it be?)

I don't recall the exact details... Didn't you generate a per-interface
bit of code? The magic with xptcall is that you don't need any compiled
code specific to the interface, you only need a description of the
interface (which is delivered in the binary code, or in "typelib" files,
and I plan on the XPLC version of the same being inlinable even in
scripting languages).

And did yours go both way (be able to implement an XPLC interface in a
scripting language)?

[Avery Pennarun]

Post by Pierre Phaneuf

Post by Avery Pennarun
My xplcidl actually implements this in a different way, avoiding the
horrible pain of manipulating stack frames and other stuff... but
potentially with a performance penalty. (Hey, you're in a scripting
language, how much worse can it be?)

I don't recall the exact details... Didn't you generate a per-interface
bit of code? The magic with xptcall is that you don't need any compiled
code specific to the interface, you only need a description of the
interface (which is delivered in the binary code, or in "typelib" files,
and I plan on the XPLC version of the same being inlinable even in
scripting languages).

Yes, you need a compiled bit of code for each interface: but if you're
delivering your typelib in "binary code" anyway, then it might as well just
be executable. There's no fundamental difference.

Inlining that kind of stuff in scripting langugages is a bit funkier, but
I'm not sure that's a good idea anyway. It reminds me of the old DATA
statement in BASIC. Yeah, you could use it, and yeah, it was fine before
they invented disks, but...

Post by Pierre Phaneuf
And did yours go both way (be able to implement an XPLC interface in a
scripting language)?

The same concept could apply either way, although I only implemented one
direction (IMHO by far the most common one for apps/libraries I know of).

Have fun,

Avery