From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 7FC1FBBC4 for ; Thu, 5 Mar 2009 22:23:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUGAPvRr0nUnwdkZGdsb2JhbACCHpJWGgkFBwcPBsMNhAgG X-IronPort-AV: E=Sophos;i="4.38,308,1233529200"; d="scan'208";a="22123033" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2009 22:23:23 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJnRr0nUnw4U/2dsb2JhbACCHtYrhAgG Received: from pih-relay08.plus.net ([212.159.14.20]) by relay.pcl-ipout02.plus.net with ESMTP; 05 Mar 2009 21:23:22 +0000 Received: from [87.112.234.120] (helo=leper.local) by pih-relay08.plus.net with esmtp (Exim) id 1LfL2I-00014f-8s for caml-list@yquem.inria.fr; Thu, 05 Mar 2009 21:23:22 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml's intermediate representations Date: Thu, 5 Mar 2009 21:28:47 +0000 User-Agent: KMail/1.9.9 References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903052044.29147.jon@ffconsultancy.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903052128.47358.jon@ffconsultancy.com> X-Plusnet-Relay: 8df0c5dd14bc8a08239c983cdc2a9d73 X-Spam: no; 0.00; ocaml's:01 lambda:01 lambda:01 bytecode:01 runtime:01 bytecode:01 reimplement:01 ocaml:01 seq:01 compiler:01 ocaml:01 2009:98 2009:98 javascript:98 javascript:98 On Thursday 05 March 2009 20:50:58 Jake Donham wrote: > On Thu, Mar 5, 2009 at 12:44 PM, Jon Harrop wrote: > > Is this [the lambda IL] format documented anywhere? > > The ocamljs backend compiles Javascript from the lambda intermediate > language. I haven't found documentation of it, but most of it is > pretty easy to understand (a few things I've had to track down by > seeing what they compile to in bytecode). You might find the > Javascript translation a useful guide, but of course don't take it as > the final word. > > You are right though that it makes some assumptions about the runtime > representation and has already erased types. It is (obviously) good > enough to be a shared IL for the bytecode and opt backends; it is > mostly good enough for ocamljs (there are some places where I wish I > knew more about the type of things); I can't say what your needs are > with LLVM. > > Still it is probably a better starting point than trying to > reimplement the OCaml front-end. That's very interesting advice, thanks, but the more I play with it the more I think it will not satisfy my needs. Consider: type t = A of int | B of int | C of int;; function A n -> n | B n -> n | C n -> n;; which compiles to: (setglobal A! (seq (function param/72 (field 0 param/72)) (makeblock 0))) The type definition is not even there and the function definition swings entirely on the uniform internal representation of the field. That is completely incompatible with HLVM. The ocamljs backend will have an easier time because it will be dynamically typing everything anyway (i.e. it also has a uniform representation). I could do that in HLVM but the performance would be atrocious because everything would be boxed, of course. I'll take a look at the pattern match compiler in OCaml and see if it is feasible to make it retain type information. Hopefully I can reuse some of this stuff. :-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e