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 pB9EUfp6016715 for ; Fri, 9 Dec 2011 15:30:42 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIBAAwb4k5KfVM2kGdsb2JhbABDqnEIIgEBAQEJCQ0HFAQhgXIBAQEDARICLAEbHAIDDAYFCw0JFg8JAwIBAgEREQEFARwTCAIeh2UCBpkeCotkgmuEWj2IcQIBBAyLZgSUcIVLgTWGcT2Dew X-IronPort-AV: E=Sophos;i="4.71,326,1320620400"; d="scan'208";a="122758759" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Dec 2011 15:30:37 +0100 Received: by eekc50 with SMTP id c50so2171715eek.27 for ; Fri, 09 Dec 2011 06:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=qUm4L+L7CEfZpKFvz4DMH0du39kERwm4jAEcM+lXSwY=; b=ISB5BV7LgEOfJ3Bc9JV+RB2mJgR1AVngBEHhdkDgPpyIobN57opar/hagcFKtRluEw uTqnkf7iGNQvcqjHBm6L2vcLXfAmqCvutJDvLG3uenGsora8nXDEgSsuXi8h+OeRk3dg v2UJnCiLdoYJzwaJ6HbDH7MgBwJwJOIohXvJU= Received: by 10.14.0.138 with SMTP id 10mr897264eeb.145.1323441036747; Fri, 09 Dec 2011 06:30:36 -0800 (PST) Received: from [192.168.1.101] ([79.114.32.139]) by mx.google.com with ESMTPS id 58sm31731582eet.11.2011.12.09.06.30.34 (version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 06:30:35 -0800 (PST) Message-ID: <4EE21B89.2010306@gmail.com> Date: Fri, 09 Dec 2011 16:30:33 +0200 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= 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: caml-list@inria.fr References: <20111209065758.94306.qmail@eeoth.pair.com> <4EE1BE59.4020804@glondu.net> <59A74C55-C12B-4C98-9496-2E83BE8A39F0@googlemail.com> In-Reply-To: <59A74C55-C12B-4C98-9496-2E83BE8A39F0@googlemail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Why NOT to compile OCaml via C On 12/09/2011 04:05 PM, Benedikt Meurer wrote: > > On Dec 9, 2011, at 13:37 , Gabriel Scherer wrote: > >>> You can follow the progress here: https://github.com/colinbenner/ocamlllvm >> >> - there are two different repos, ocamlllvm and ocaml-llvm (which has a >> commit history that make it looks like it is where the real >> development happen); which one should one follow? A wild guess after >> only a quick look is that the ocaml-llvm repo did not build upon your >> ocamlnat changes, and ocamllvm is about merging the changes on top of >> it; but I really have no idea. > > ocaml-llvm was the initial attempt, based on the upstream OCaml sources. But we decided to ditch the surrounding OCaml stuff, esp. the broken make-based build system in favor of something simple, based on oasis and ocamlbuild (just like I did with ocamlnat). So the one to follow is ocamlllvm. > >> - you mention a "patched" LLVM; where can the patches be fetched? > > Just drop Colin a mail and ask him for the current patch (should be for 2.7 or 2.8, IIRC). FWIW 3.0 has some fixes in the OCaml bindings that may (or may not) be useful for you, like: findlib support, string_of_lltype not dieing on recursive structs, bindings to ipo.h, bindings to some additional C APIs that were missing from the OCaml ones, support for creating landing pads. 3.0 changes how structs work fundamentally though (they are not merged based on structure anymore), so it may not be an easy change to move from 2.8 to 3.0, and I see why you would want to stay with 2.8 for now. > >> Do >> you plan to present changes in such a way that it can be submitted >> upstream? > > Yes, the long time goal (maybe impossible to reach with just one bachelor thesis) is to have a simple set of patches for LLVM (mostly calling conventions, maybe some additional intrinsics for the weird OCaml exception model), which can be merged upstream. > >> I think it is natural that you have to make changes to LLVM, >> the GHC people (which now have an experimental LLVM backend) also did, >> and I was under the impression that the LLVM people where quite >> welcoming of their changes, they are glad to see LLVM being used in a >> non-Clang-centric project. I think your patches could bring value to >> LLVM, independently of the success of the ambitious ocaml backend >> attempt. > > Hm, I'm not sure. It's really easy to generate LLVM code for OCaml in general, the problem is getting things to interact with legacy OCaml code, with exception handling being one of the most important issue. The required stuff will be very platform specific and very specific to OCaml, and we don't even know if it's going to work. Is binary compatibility with a specific version of ocamlopt necessary? I think that ocaml-llvm could detect the mismatch and print an error, like you get for an ABI mismatch. Sure it'd be nice to be able to try out ocaml-llvm without rebuilding all OCaml packages, but such a rebuilt is required when new OCaml releases come out anyway, as they are usually not ABI compatible with each-other. Best regards, --Edwin