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
