Re: Languages with well-integrated Foreign Function Interface to learn from?

"Christoffer Lernv" <lerno@dragonascendant.com> wrote in message
> I'd like to research FFI in various languages, basically to find the
> best FFI-solution and copy from that one.
> It's likely that I will restrict myself to interfacing with C, so if
> there are elegant solutions integrating with C, and more clunky but
> flexible that are more general, I probably prefer the ones that
> exclusively target C.
>


targetting C is IMO a good idea, as most other languages are able to operate
(at least, to some extent) at the level of C.




> What I'm looking for is syntax, to what extent automatic conversion of
> arguments are done, how to handle callbacks, memory management, how to
> create structured data (i.e. structs in the case of C) etc.
>


rough comment:
try to keep the "interface" as "thin" as possible ("glue code" should
hopefully also be kept as "thin" as possible).


this could mean:
using an internal structure "similar" to that of the outside world (after
all, sharing memory and structs is nowhere near as difficult if both sides
use essentially the same representation);
possibly, the use of automatic code generation (namely: producing/assembling
machine code or ASM at runtime).


both of these options may greatly increase the work of implementing the VM,
but if the interface can be done "near" or "at" native level, then the FFI
can become nearly automatic.


dynamic code production also helps some in that it allows interfacing with
code which is not statically linked against the host app (for example,
grabbing and interfacing with DLL's, ...).


similarly, it is IMO worth investing in a full C-style parser (at least),
such that native headers can be used in constructing the interface.


for example, all of the various declarations, prototypes, typedefs, ... can
be parsed, and when it is needed to call something, the DLL's can be loaded,
the code can be automatically generated, and the function made available to
the VM.




granted, this is not the "path of least effort", and there are approaches
which would require less work (as well, there are approaches which require
more work, but which can nearly eliminate the distinction between the VM's
managed code and native code, such that the interface is essentially
transparent for both parties).


this requires making the code, data, ... more or less indistinguishable at
the lower levels (AKA: to avoid structure-interfacing issues, internally use
C's structure layout, and to call native code, use C's calling conventions
as well, ...).


(note that a lot of this more or less assumes the availability of JIT, which
can be noted are a fairly harsh jump from the use of plain interpreters...).




granted, one of the "simplest" FFI's (and also the least transparent), is to
write a whole lot of wrapper code to interface native code with the VM.


maybe JNI is an example of this approach.


P/Invoke is an example of a more "middle of the road" strategy (more work in
the VM than JNI, but provides a basic interface without the need for wrapper
code).


> [Someone asked roughly the same question in 1997, but got no
> answers. Poking around on the net, all the FFI seems rather ad-hoc
> and language specific. -John]


agreed.


actually, FFI depends much more on VM design than on language IMO, but often
these are closely related anyways.

Return to the comp.compilers page.
Search the comp.compilers archives again.