From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB97r4qY032108 for ; Fri, 9 Dec 2011 08:53:04 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcDAE294U6K54gDgWdsb2JhbABDhQalayIBARYmJYFyAQEFI1UBEAsaAgUWCwICCQMCAQIBRRMBBQICiAWldJErgTSGb4IEgRYElGqFS4xd X-IronPort-AV: E=Sophos;i="4.71,325,1320620400"; d="scan'208";a="122700502" Received: from rouge.crans.org ([138.231.136.3]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 09 Dec 2011 08:52:58 +0100 Received: from localhost (localhost.crans.org [127.0.0.1]) by rouge.crans.org (Postfix) with ESMTP id 6E39E85BF; Fri, 9 Dec 2011 08:52:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at crans.org Received: from rouge.crans.org ([10.231.136.3]) by localhost (rouge.crans.org [10.231.136.3]) (amavisd-new, port 10024) with LMTP id 6LIHOSHbrEX5; Fri, 9 Dec 2011 08:52:58 +0100 (CET) Received: from [192.168.39.1] (fbx.up7.fr [81.56.96.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by rouge.crans.org (Postfix) with ESMTPSA id 291F085BD; Fri, 9 Dec 2011 08:52:57 +0100 (CET) Message-ID: <4EE1BE59.4020804@glondu.net> Date: Fri, 09 Dec 2011 08:52:57 +0100 From: =?UTF-8?B?U3TDqXBoYW5lIEdsb25kdQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: oleg@okmij.org CC: caml-list@inria.fr, ontologiae@gmail.com, caml@inria.fr References: <20111209065758.94306.qmail@eeoth.pair.com> In-Reply-To: <20111209065758.94306.qmail@eeoth.pair.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=49881AD3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pB97r4qY032108 Subject: Re: [Caml-list] Why NOT to compile OCaml via C 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