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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id B2278BC57 for ; Thu, 2 Dec 2010 02:17:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4AAOOB9kxKfVM0k2dsb2JhbACUX4YrAYc2WAgVAQEBAQkJCgkRBB6pJYlkghiEay6IVgEBAwWCDoM0BIpm X-IronPort-AV: E=Sophos;i="4.59,285,1288566000"; d="scan'208";a="82132821" Received: from mail-gw0-f52.google.com ([74.125.83.52]) by mail2-smtp-roc.national.inria.fr with ESMTP; 02 Dec 2010 02:17:21 +0100 Received: by gwj18 with SMTP id 18so1420830gwj.39 for ; Wed, 01 Dec 2010 17:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VFoBHlrzuKdV43aQIRISuPwekVN/3vLuVWCeyFG2S1E=; b=SlJZXDyr3fHb+g/Gu2RNMpWDsNhImwegIWlAohz6ZcB6vmeMXa/QElXvw5Uw31o5Iy NC4+ermZqk0gbZbPV6sWjYBtKtwrlbaK8eSi78R5Pbo2R8u5TSvMn77xeij5XncAmhrw /zClXDhw2v/CtqN4gzw0JXyySuGqSreWGp/6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q1uS5Z/TUhlDGSRbukzkqHNMjfzYCHgI8LjbzX9MfBX52assfyET5UmMwuuW86psyH beP5UN6e51u2urfev4ycKd7JSrMK4UB3U+yZKsUuBSvXoTdpQCtp0z62f01g2dvZ70U0 yBfPJONrWXqjrFX9eqoODDC1PxQlcnG2ExQ68= MIME-Version: 1.0 Received: by 10.91.17.20 with SMTP id u20mr277951agi.96.1291252640300; Wed, 01 Dec 2010 17:17:20 -0800 (PST) Received: by 10.90.211.10 with HTTP; Wed, 1 Dec 2010 17:17:20 -0800 (PST) In-Reply-To: <0b9301cb91a3$8f42fd60$adc8f820$@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> Date: Thu, 2 Dec 2010 03:17:20 +0200 Message-ID: Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT From: Eray Ozkural To: Jon Harrop Cc: Benedikt Meurer , caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=00163646db7ef0be2f0496632eef X-Spam: no; 0.00; eray:01 ozkural:01 gcc:01 high-level:01 low-level:01 ocaml:01 compiler:01 high-level:01 compiler:01 ocaml:01 eray:01 ozkural:01 bilkent:01 gcc:01 low-level:01 --00163646db7ef0be2f0496632eef Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 2, 2010 at 12:03 AM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > > > > > As does assembler, so even more reasons to emit assembler? > > LLVM makes it a *lot* easier to generate efficient code, of course. Just like the way gcc is using a hierarchy of program representations from high-level to low-level, an ocaml compiler could in principle perform type and language specific optimization passes in the high-level (cmm for instance) and then emit llvm code, without any loss of efficiency, I think. Still, I have to agree with other posters stating that a compiler backend written in ocaml is preferable. I agree, if not only for the reason that I know from experience it would be 10 times easier to write in ocaml some of the passes I have had to deal with in C++. Even working with symbols is quite awkward in C++. While on the other hand, libraries like boost can help at times, but it is nothing we cannot replicate in ocaml. As a compiler developer, I would be most intrigued in profiling and static analysis information represented in ocaml. I don't see why hybrids are a bad idea, though. If you see LLVM becoming an industry standard, then, of course it's worth supporting. It means you'll target new architectures with no effort. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --00163646db7ef0be2f0496632eef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 2, 2010 at 12:03 AM, Jon Harrop <jona= thandeanharrop@googlemail.com> wrote:
>
> As does assembler, so even more reasons to emit assembler?

LLVM makes it a *lot* easier to generate efficient code, of course.

Just like the way gcc is using a hierarchy o= f program representations from high-level to low-level, an ocaml compiler c= ould in principle perform type and language specific optimization passes in= the high-level (cmm for instance) and then emit llvm code, without any los= s of efficiency, I think.

Still, I have to agree with other posters stating that = a compiler backend written in ocaml is preferable. I agree, if not only for= the reason that I know from experience it would be 10 times easier to writ= e in ocaml some of the passes I have had to deal with in C++. Even working = with symbols is quite awkward in C++. While on the other hand, libraries li= ke boost can help at times, but it is nothing we cannot replicate in ocaml.= =A0As a compiler developer, I would be most intrigued in profiling and stat= ic analysis information represented in ocaml.

I don't see why hybrids are a bad idea, though. If = you see LLVM becoming an industry standard, then, of course it's worth = supporting. It means you'll target new architectures with no effort.

Best,

--
Eray Ozkural, PhD candidate= .=A0 Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosop= hy
http://myspace.com/arizanesil= http://myspace.com/malfunct
--00163646db7ef0be2f0496632eef--