English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
OCamlJIT2 vs. OCamlJIT
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-12-06 (08:27)
From: Benedikt Meurer <benedikt.meurer@g...>
Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT)

On Dec 5, 2010, at 23:34 , Erik de Castro Lopo wrote:

> Benedikt Meurer wrote:
>> Using a different data representation within OCaml would indeed be
>> possible, but one has to ask what it's worth?
> Is it necessary to use a different data representation? What does
> that buy you?

Read my mail again please, it was all about the data representation issues.

>> the standard
>> library and the bytecode interpreter (already a massive amount of
>> work),
> Why?

Because you want to keep the bytecode interpreter in sync, otherwise you can no longer share any piece of C code between ocamlopt and ocaml/ocamlrun.

>> but you also loose compatibility with almost every existing OCaml
>> library binding, since the native function interface will be different.
>> That's a hell of a lot of work for many people.
> Again, why?
> When the GHC haskell compiler gained an LLVM backend, the LLVM project
> accepted changes to allow a new GHC specific calling convention. Couldn't
> the same be done for Ocaml?

This is not about calling conventions, and also not about LLVM. This is about data representation.

>> 3. The current garbage collector is mostly straight-forward because of
> There is no need to use LLVM's GC if something better already exists.

LLVM does not provide a GC.

>> Two main areas for now: The GC interface and the exception handling.
> If the Ocaml versions of these are already better than what LLVM can
> provide, here is no reason to use the LLVM versions.

It isn't as simple. With LLVM you are no longer in control of the code generation. The "ocaml versions" use special registers and stack layout, which will not work with LLVM's code generation unless LLVM is patched appropriately.

> Erik