Re: Native toplevel? (was: OCamlJit 2.0)

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Nov 17, 2010, at 09:44 , Alain Frisch wrote:

> 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.

This is indeed very interesting. I haven't thought of the native top-level. I haven't done any measurements yet, but from my experience with ocamlopt, I know that the optimizing native compiler is somewhat slower than the byte-code compiler. I doubt that this is related solely to the external as/ld invocations, so there's certainly more work to do than just replacing the calls to as/ld with an in-process assembler/linker.

> -- Alain

Benedikt