extended foreign decls

Fergus Henderson fjh at cs.mu.oz.au
Wed Jan 3 05:28:17 EST 2001


On 03-Jan-2001, Tyson Richard DOWD <trd at cs.mu.OZ.AU> wrote:
> On 03-Jan-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > * As I understand, these pragmas are supposed to support not
> >   only C.  How about C++ code?  Will there be a C++ backend
> >   for Mercury just to make this code efficient?
> 
> No.  There's only (at most) one language per backend that can be inlined
> in this way.

Actually that's not necessarily true.  For example, the current
Mercury compiler compiles via C and then via asm.  We could probably
support both inline C and inline asm.  Currently we don't bother
to support inline asm, since (a) we've never needed it and (b)
you can get the same effect by writing inline asm inside your inline C
(presuming the C compiler supports inline asm), but I wouldn't be
too surprised to see it in the future.

I also wouldn't be surprised to see a C++ backend for Mercury.
Given that we already support a C back-end, a C++ back-end would
not be difficult to implement.

> Otherwise you have to do your best.  You can inline the C
> wrapper code that is used to call into C++, but that's about it.

The way to make the inlining trick work across multiple languages
is to provide either (a) a single definition that works in
multiple languages, and then inline it into all those languages
or (b) provide different definitions for different languages,
and then use the appropriate version depending on which target
language you are compiling to.

For those who are not fans of polyglot-style obfuscated programs,
(a) generally only works in the case of languages which are
syntactically quite similar, such as C and C++, where you can easily
write code that is in the intersection of both languages.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.




More information about the FFI mailing list