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-05 (22:34)
From: Erik de Castro Lopo <mle+ocaml@m...>
Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT)
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?

> 1. You will have to rewrite not only the compiler,

At least the compiler backend, and the new backend might require
changes in earlier stages earlier of the compiler.

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


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

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

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

I'm currently working on the LLVM backend to an experimental compiler
called DDC:


DDC had an existing C backend and its own garbage collector. For the
LLVM backend I have kept the C calling convention and the existing
GC and just used LLVM for code generation.

In my experience, LLVM has been a pleasure to work with, but the
backend is not yet far enough advanced for any speed comparisons
between the C and LLVM backend.

Erik de Castro Lopo