Re: [Caml-list] Why NOT to compile OCaml via C

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> I find the idea of making ocamlopt a GCC (or
> LLVM) frontend the most sensible and constructive one I've seen in these
> discussions.

Note that, besides Oleg excellent description of some issues, the idea
has already been discussed a few times before, here and on llvm-dev:
- http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011525.html
(discussion on llvm-dev)
- http://caml.inria.fr/pub/ml-archives/caml-list/2010/11/315de2fb3656166edba13bb657fa691f.fr.html
(Benedikt Meurer: why ocamljit2 isn't an LLVM backend)
- https://sympa-roc.inria.fr/wws/arc/caml-list/2011-08/msg00192.html
(Pierre-Alexandre Voyes: question about a C backend; further
discussion of the DDC case)
- https://sympa-roc.inria.fr/wws/arc/caml-list/2011-08/msg00003.html
(Wojciech Meyer: announcement of an ocaml compiler framework project
with goal and structure similar to LLVM)

I found back some of this links thanks to the excellent "OCaml Weekly
News" summary:
  http://alan.petitepomme.net/cwn/2011.08.02.html
(Where Benedikt announces that he has a student working on an LLVM backend.)

OCamlPro also published an internship offer for an LLVM backend.

Apparently, there was at the time no particular interest among the
existing OCaml compiler hackers to develop such a C, LLVM or what you
have backend. Lots of people are talking about it, but few actual work
is done, or at least publicly exposed. I guess everyone would be happy
to look at an good LLVM backend, *especially* it is complete, stable,
safe enough to be a potential candidate for integration (if the work
needed between the working prototype and an integration is huge and
nobody is interested in doing it, it will remain at a prototypical
stage) but I will believe it when I see it.

I'm confident both Benedikt and/or OcamlPro (or other parties that I
don't know) would have the expertise to do something very good in this
direction, and I hope they'll go forward with this. It's just that I
don't feed the need for another bunch of emails about how LLVM passes
are great, GC issues, JIT or not JIT, performances of the current
Javascript engines, how frustratring it is that emacs is as slow to
start today as it was ten years ago, and the good and bad of Python's
meaningful-indentation syntax.

> However, one barrier is the licensing: QPL is incompatible with almost
> any license (even QT does no longer use it!). Has it ever been
> considered to switch the "public" license to e.g. GPLv3 (which looks
> constraining enough, and compatible with GCC)?

Stéphane, I am surprised at how good your are at raising trollish topics !

I don't think now is a good time to discuss this; maybe we should wait
for dust to settle on the other trolls before restarting a
"discussion" (where everyone agrees, but BSD or GPL?) on this.

On Fri, Dec 9, 2011 at 8:52 AM, Stéphane Glondu <steph@glondu.net> wrote:
> Le 09/12/2011 07:57, oleg@okmij.org a écrit :
>> There are at least two other reasons ocamlopt emitting assembly. One
>> is garbage collection. OCaml GC is precise. Therefore, when sweeping
>> through the stack, GC has to know if 0x80aa4000 is an unboxed integer
>> or a heap pointer. So-called frame tables generated by the compiler
>> tell GC which stack slots contain OCaml values. GC ignores other slots
>> and hence expensive tests it had to do otherwise. One can build frame
>> tables only when one has full control of the generated code and the
>> frame layout. The third reason is exceptions. In OCaml, exceptions are
>> pervasive and should be fast. They are indeed well implemented, via
>> special exception frames and a dedicated exception frame `register'
>> (which is a real register on x64).
>
> C sure is not a good target language, but assembly is not either.
> The assembly backends of ocamlopt (and GHC... there is no support at all
> on some Debian ports) look like a maintenance burden that their authors
> obviously cannot cope with. I find the idea of making ocamlopt a GCC (or
> LLVM) frontend the most sensible and constructive one I've seen in these
> discussions.
>
> However, one barrier is the licensing: QPL is incompatible with almost
> any license (even QT does no longer use it!). Has it ever been
> considered to switch the "public" license to e.g. GPLv3 (which looks
> constraining enough, and compatible with GCC)?
>
>
> Cheers,
>
> --
> Stéphane
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>