Native toplevel? (was: OCamlJit 2.0)

[Alain Frisch <alain@frisch.fr>]

On 11/16/2010 03:52 PM, Benedikt Meurer wrote:
> OCamlJit 2.0 was specifically designed for desktop processors and is
> not really portable to anything else in its current shape, because
> the target audience are people using the interactive top-level and
> the byte-code interpreter for rapid prototyping/development

This looks like a very interesting project!

Does performance really matter that much for rapid 
prototyping/development?  I can imagine other uses of the toplevel where 
performance matters more, like theorem provers embedded in the OCaml 
toplevel.

Anyway, another option to get a more efficient interactive top-level is 
to turn to native code.

There is actually already a native top-level in the distribution, even 
though it is undocumented and unmaintained.  You can build it with the 
"make ocamlnat" target.  The implementation is based on the same 
approach as native dynlink.  The toplevel embeds the native compiler; 
for each phrase, the toplevel produces assembly code, calls the 
assembler and the linker to produce a dynamic/shared library, and then 
dynamically load and execute the resulting code.  This gives some 
latency, but it's not so bad in practice, and you get the full speed of 
native code.

A further step to improve this native toplevel is to avoid the call to 
the external assembler and linker.  To do that, one basically needs to 
replace the assembly code emitters (emit.mlp/emit_nt.mlp) with native 
code emitters and do the relocation/dynamic loading by hand, which is 
quite easy.

As it turns out, LexiFi uses on a daily basis such direct binary code 
emitters for x86/amd64 on Windows, and that would be easy to port to 
other x86/amd64 platforms.  The x86 version was developed internally, 
and the amd64 version was done by Fabrice Le Fessant.  There is also 
some code to wrap the binary code into COFF objects (and flexdll has a 
stand-alone mode to produce .cmxs files without an external linker), but 
that would be useless for a native toplevel. The goal was to have a 
compiler which can be more easily embedded in our applications and 
deployed to our customers, without depending on any external tool.


If you Benedikt, or someone else, is willing to work on a native 
top-level without the need to call an external assembler/linker, we are 
ready to extract the binary code emitters from our code base and share 
them with the community (with an open-source license to be determined). 
This requires some packaging work on our side, so we're going to do it 
only if there is interest in the project.


(Another nice side project, for having a good native toplevel, would be 
to extend ocamlopt with some control over the trade-off between speed of 
code generation, and the performance of the generated code. One way to 
do it is to force the interference graph to remain not too big, by 
spilling early, in order to avoid quadratic behavior in the register 
allocator.)


-- Alain