Custom calling conventions

[Manu]

On 21 February 2012 21:03, Paulo Pinto <pjmlp at progtools.org> wrote:

> I think this fails in the same trap as extern "language" in C++.
>
> Besides C and C++, I think the only variation I saw so far for the
> language part has been fortran, and cannot recall anylonger in what
> compiler it was.
>
> In C++'s case, since it is implementation defined, most compiler vendors
> did not bother to support more than what the standard specifies (C and
> C++).
>
> In you proposal, how to keep the feature portable across D implementations?
>

Well since the languages I'm using as examples are VM based, the
interaction is through a standardised API, which is most likely part of the
same module that defines the custom extern type, both would be presented in
the same package.


If you make it part of D language specification, which languages would be
> the chosen ones to be made available in any D compiler?
>

I'm not making any language part of the D specification, I'm suggesting a
system to integrate custom calling code, which can be introduced in
libraries. No intrinsic support in D for any particular language.


How to garantee correct interoperability (ABI) with other languages? After
> deciding the set of chosen languages, which compilers/runtimes would be the
> lucky ones?
>

VM based languages have a strictly defined API, this is guaranteed, no
problem.
Extern to hard-linking languages requires the extra bits I detailed in a
prior post (name mangler, call receiver), and probably some version() mess
to support different compilers just like C/C++ does all over the place.
Many C compilers can't link against each others binaries, but with a mature
lib, you'd be able to support the calling convention of popular compilers
for your language of interest I would think.
t's probably quite do-able, but I'm not proposing to take the system that
far initially. Custom calling conventions to integrate with VM's seems more
useful, and much simpler to start with.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120221/43e7eaf5/attachment.html>