From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 7D6AFBBAF for ; Mon, 6 Dec 2010 09:27:46 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkBAKUt/EzRVdY0gWdsb2JhbACVHY4MCBUBAQsJCgcTBB6jM4wCAQWNDwEEghSDNQ X-IronPort-AV: E=Sophos;i="4.59,305,1288566000"; d="scan'208";a="82060004" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 06 Dec 2010 09:27:46 +0100 Received: by bwz4 with SMTP id 4so10162557bwz.39 for ; Mon, 06 Dec 2010 00:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=A3a2rWrFD3iZCFpEoUs8mQ8Rx4V0Pgkp5vTQxJirFQ0=; b=XhzhZNErzm6ZKOvramFCxznIK3MiQNjaZLImhq7Yr1aGYW2tTDPZToQRmvlg4TSrcT i5IMmttNNrcDthWO2uIgWg4MQ9gp4RPENk7e/mTpDQ52k2bloqYWy1CYBQ0UY8t/2x9Q CPm4mlrKE1JkBKM17kzAybG+g/vDxowP32Cdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=paMD3Mfbv7KbdcMqw/e9aVX3gBvF8vkhuGiRw/F/B2l205fbTDMMNTDWOJWSfZDab3 DU6iJyYo3sV1cJK+AL9uUwkoheRoVWVtRE8dQAUo/6FKOvhz867bptWDRZeU0mZZ+Hax tun2jZsoneTHC/Duc73ACXGLlcspYYr8+aEPE= Received: by 10.204.60.79 with SMTP id o15mr5447608bkh.5.1291624065480; Mon, 06 Dec 2010 00:27:45 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id f12sm2116976bkf.4.2010.12.06.00.27.43 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 00:27:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) From: Benedikt Meurer In-Reply-To: <20101206093412.e2de2d5c.mle+ocaml@mega-nerd.com> Date: Mon, 6 Dec 2010 09:27:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB7EA68-E945-4EC4-9576-2EE75B3B9070@googlemail.com> References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> <0a8b01cb90da$da5e6240$8f1b26c0$@com> <5E2DA3F1-7998-4F62-B617-7B6451D1001D@googlemail.com> <0b3b01cb9161$a81c8e10$f855aa30$@com> <0b9301cb91a3$8f42fd60$adc8f820$@com> <0cae01cb9325$a8ddc3d0$fa994b70$@com> <20101206093412.e2de2d5c.mle+ocaml@mega-nerd.com> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; ocamlopt:01 ocaml:01 bytecode:01 bytecode:01 ocamlopt:01 ocaml:01 ocamlrun:01 haskell:01 compiler:01 patched:01 garbage:01 wrote:01 wrote:01 stack:01 exception:01 On Dec 5, 2010, at 23:34 , Erik de Castro Lopo wrote: > Benedikt Meurer wrote: >=20 >> Using a different data representation within OCaml would indeed be >> possible, but one has to ask what it's worth? >=20 > Is it necessary to use a different data representation? What does > that buy you? Read my mail again please, it was all about the data representation = issues. >> the standard >> library and the bytecode interpreter (already a massive amount of >> work), >=20 > Why? Because you want to keep the bytecode interpreter in sync, otherwise you = can no longer share any piece of C code between ocamlopt and = ocaml/ocamlrun. >> but you also loose compatibility with almost every existing OCaml >> library binding, since the native function interface will be = different. >> That's a hell of a lot of work for many people. >=20 > Again, why? >=20 > When the GHC haskell compiler gained an LLVM backend, the LLVM project > accepted changes to allow a new GHC specific calling convention. = Couldn't > the same be done for Ocaml? This is not about calling conventions, and also not about LLVM. This is = about data representation. >> 3. The current garbage collector is mostly straight-forward because = of >=20 > There is no need to use LLVM's GC if something better already exists. LLVM does not provide a GC. >> Two main areas for now: The GC interface and the exception handling. >=20 > If the Ocaml versions of these are already better than what LLVM can > provide, here is no reason to use the LLVM versions. It isn't as simple. With LLVM you are no longer in control of the code = generation. The "ocaml versions" use special registers and stack layout, = which will not work with LLVM's code generation unless LLVM is patched = appropriately. > Erik Benedikt=