> 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 <[email protected]> wrote: > Le 09/12/2011 07:57, [email protected] 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 > -- 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
