Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] calling native code from bytecode?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] calling native code from bytecode?
> 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

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

- Xavier Leroy
Bug reports:  FAQ:
To unsubscribe, mail  Archives: