> So, just to be excruciatingly clear, assuming there are no closures
> in any of the parameters to a function call, the "values" passed in
> and any native code and GC operations on those values are completely
> compatible?  Even for arbitrarily complex datastructures, as long as
> no closures are in the mix?

As far as I can remember, yes.

> If I constrained the problem to just leaf functions (where leaf is
> defined as never calling back into bytecode) then it would work,
> runtime library-wise?

No :-)  From the standpoint of the runtime system, Caml-generated
native code and the bytecode interpreter differ in several points:

- the location of GC roots (e.g. native stack vs. bytecode interpreter
  stack);
- how to raise exceptions from C code;
- how to call back from C to Caml.

To handle these differences, the runtime system comes in two variants
(libcamlrun.a and libasmrun.a), with suitable #ifdefs, different
definitions of some runtime functions, etc.  Linking with only one
version of the runtime system (e.g. libcamlrun.a) will result in wrong
behavior for mixed-mode code, e.g. the GC will overlook memory roots
residing in the native code stack.  Linking with both versions is not
possible, as they define differently the same function names...

(It might be possible to play linker tricks so that there are actually
two copies of the runtime system in the executable, but then you'd
have two different Caml heaps, one for the bytecode system and one for
the native code, and you'd need to copy all data structures when
switching between bytecode and native code.  Quite messy.)

My advice is: don't do it.  If all you need is to have the
efficiency of native code and the debugging comfort of bytecode, just
compile all your sources twice, to native-code and to bytecode.  For
dynamic loading of bytecode in a native-code application, Fabrice Le
Fessant's asmdynlink library (or something similar) should suffice.
And I can't see any other reason why you'd want mixed-mode execution.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr