> Is there any way to compile part of a project in bytecode and another
> part with the native compiler and link them?  It seems odd that you
> can call C from bytecode but not other caml code.  The gc and
> everything is the same between the asm and bytecode runtimes, no?  Are
> datastructures in memory (except code, of course) compatible?

Yes, they are compatible, except function closures, which contain
native code pointers for ocamlopt and byte-code pointers for ocamlc.
But that's where the problem is for mixed-mode execution: treating
pointers to bytecode and pointers to native-code differently.  

One solution would be to have two code pointers per closure, one
bytecode and one native-code.  For a bytecode closure, the native-code
pointer would point to the bytecode interpreter.  For a native-code
closure, the bytecode pointer would point to a special "switch mode"
instruction of the virtual machine.  But that's far from easy to
implement.

Another approach is Fabrice Le Fessant's asmdynlink library, which
basically is a bytecode interpreter written in Caml and compiled with
ocamlopt.  This gives native-code programs the ability to execute
bytecode, albeit at a fairly large cost in execution speed.


> Basically, I've got some numerical code that I'd like to compile to
> native code for performance, but I'd like to keep most of the
> non-performance stuff in bytecode so I can use the toplevel and
> whatnot.  I suppose I could do some sort of heinous bytecode -> C ->
> native code shim

Besides problems with potential callbacks from native-code to
bytecode, there are also (non-essential, but intricate) GC issues that
would come in the way.

> Obviously, the holy grail would be complete intermingling of bytecode
> and native code, and the linker just figures it out and does the right
> thing.  That would rock.  But, I'd settle for bytecode -> native calls
> only at this point.
> Thoughts?

Nothing is impossible, but I shudder at the idea of implementing all
this.

- 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