Re: [Caml-list] dynamically loading C functions

[Chris Hecker <checker@d6.com>]

>I've written a Dlopen module for x86 and alpha available at
>http://pauillac.inria.fr/~lefessan/src/dlopen.tar.gz

Neat!  This is a very nice type hack to get the return value parameterizable with format:

val dlsym : dll -> string -> ('c -> 'a,unit, 'c) format -> 'a

When I was thinking of using the printf format strings, I couldn't figure out how to get the implicit 'c return value out of there on the result, but putting it in the first type argument as well is ingenious!

Does this library ever build closures around C functions and pass them back to caml (like you mentioned in a previous mail)?  I don't see the code that does that anywhere.

 From looking at the cmmgen.ml source, it looks like closures are a pretty simple layout (there's a header before these):

if physical arity 1:
word: pointer to function
word: 3 (arity (as caml int 1 lsl 1 + 1))

if physical arity > 1:
word: pointer to a curry function generated at link time
word: arity
word: pointer to function

But I've only looked at x86 so far.  The compiler actually is pretty smart (as if we didn't know that already :).  From what I can tell, if a module has been compiled, the cmx file (and maybe the cmi file) has extra information in it about the physical arity of its functions, so when they're called from another module, the compiler can just directly call the function rather than grovel around in its closure datastructure to find its physical arity (or call a subroutine to do this, which is what happens if you haven't compiled a module and you call a function in it, or just have an mli file but no ml file backing it).  I guess this is one of the currying optimizations people have been talking about.  I wonder how compilation-unit-order-dependent this is...

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr