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 p71FTUDU000408 for ; Mon, 1 Aug 2011 17:29:30 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFABrGNk7RVdU2kGdsb2JhbABBmByHJoYggXcIFAEBAQEJCQ0HFAQhgUABAQEBAgESAiwBASwLAQQLCwsHEyEiEgEFAQoEDgYTEhCHSgSifgqPAwGOBAWGQoJUkCuMTDyDXQ X-IronPort-AV: E=Sophos;i="4.67,301,1309730400"; d="scan'208";a="104440279" Received: from mail-yw0-f54.google.com ([209.85.213.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 01 Aug 2011 17:29:24 +0200 Received: by ywm39 with SMTP id 39so1243720ywm.27 for ; Mon, 01 Aug 2011 08:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Suj5ztsbg81mP48U+ILo8yxJ1USsj1f5teeJBidCYaU=; b=Y+IVOo8o8Fo4puuybUZuY/4InwNEwOAtd5Go8TeqnYzciKiIylyptBkwuNFHtzc3Jh zYPM1puHlf/Rl3uC59h+ltPC2iuZ5uR+oPNfbUd0f3nyU5fHprQZdFbYmVP8Xj+gW5Bb LFO55OyS5lCB7w1hmQnCy/+OcsLuAjJT1r1oI= MIME-Version: 1.0 Received: by 10.150.75.14 with SMTP id x14mr942562yba.73.1312212563498; Mon, 01 Aug 2011 08:29:23 -0700 (PDT) Received: by 10.151.112.10 with HTTP; Mon, 1 Aug 2011 08:29:23 -0700 (PDT) In-Reply-To: <93199F3B-E9CF-4D93-9B2B-BAAB03F4FC08@googlemail.com> References: <93199F3B-E9CF-4D93-9B2B-BAAB03F4FC08@googlemail.com> Date: Mon, 1 Aug 2011 16:29:23 +0100 Message-ID: From: Wojciech Meyer To: Benedikt Meurer Cc: caml-list@inria.fr, Marcell Fischbach Content-Type: multipart/alternative; boundary=000e0cd39c88b7979704a9734b56 X-Validation-by: wojciech.meyer@googlemail.com Subject: Re: [Caml-list] Linear Scan Register Allocator for ocamlopt/ocamlnat --000e0cd39c88b7979704a9734b56 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 1, 2011 at 3:53 PM, Benedikt Meurer < benedikt.meurer@googlemail.com> wrote: > Hello, > > As mentioned earlier we have a student working on an implementation of the > Linear Scan Register Allocator [1] for ocamlopt (and thereby ocamlnat). It > took some time, but now there's a first working patch which looks promising. > This work is done by Marcell Fischbach as part of his diploma thesis. The > idea is to use the linear scan algorithm to drive the register allocation in > the native top-level ocamlnat at some point, as suggested by Fabrice Le > Fessant [2]. > > Marcell is now working to implement a proof-of-concept of an inline > assembler for ocamlnat on i386 based on code from Alain Frisch an Fabrice Le > Fessant. The result will also be contributed once ready, and will be used to > effectively compare ocamlnat and the byte-code ocaml top-level. > > The linear scan implementation reuses as much of the existing ocamlopt > functionality as possible, so additional maintenance overhead should be > manageable. Comments and suggestions are welcome of course. Please keep > Marcell CC'ed with any replies as he's not subscribed to the list. > Hello Benedikt, It's also worth to note that there is some generic mid/back-end code ready, in my OCaml native compiler framework called DragonKit in a spirit of LLVM, which I am currently actively working on. It's already able to express a toy language and JIT compile and run it within the same process on top of x86 architecture: The code includes: - SSA based IL using polymorphic variants - monadic code generator - plugable passes using first class modules - very ad-hoc register allocator - X86 backend - example that evolved from LLVM kaleidoscope ported to DragonKit to Pascal/ML like language, and another example using direct translation to X86 backend. The code is functorised and almost purely functional (with few exceptions where there is no benefit of doing that). Maybe it could have some use in your new toplevel, or maybe it would be worth to reuse some of your work in DragonKit (or viceversa). I welcome anybody wanting to join me in this effort. Please take a look at: www.github.com/danmey/DragonKit Cheers; Wojciech greets, > Benedikt > > > [1] http://portal.acm.org/citation.cfm?id=330250 > [2] > http://caml.inria.fr/pub/ml-archives/caml-list/2010/11/a1b0ed0934ff51df4ac07c5e9da6e9d6.en.html > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --000e0cd39c88b7979704a9734b56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 1, 2011 at 3:53 PM, Benedikt Meu= rer <benedikt.meurer@googlemail.com> wrote:
Hello,

As mentioned earlier we have a student working on an implementation of the = Linear Scan Register Allocator [1] for ocamlopt (and thereby ocamlnat). It = took some time, but now there's a first working patch which looks promi= sing. This work is done by Marcell Fischbach as part of his diploma thesis.= The idea is to use the linear scan algorithm to drive the register allocat= ion in the native top-level ocamlnat at some point, as suggested by Fabrice= Le Fessant [2].

Marcell is now working to implement a proof-of-concept of an inline assembl= er for ocamlnat on i386 based on code from Alain Frisch an Fabrice Le Fessa= nt. The result will also be contributed once ready, and will be used to eff= ectively compare ocamlnat and the byte-code ocaml top-level.

The linear scan implementation reuses as much of the existing ocamlopt func= tionality as possible, so additional maintenance overhead should be managea= ble. Comments and suggestions are welcome of course. Please keep Marcell CC= 'ed with any replies as he's not subscribed to the list.

Hello Benedikt,

It's also worth to note th= at there is some generic mid/back-end code ready, in my OCaml native compil= er framework called DragonKit in a spirit of LLVM, which I am currently act= ively working on. It's already able to express a toy language and JIT c= ompile and run it within the same process on top of x86 architecture:

The code includes:
- SSA based IL using polymorphic variants
- mo= nadic code generator
- plugable passes using first class modules
- ve= ry ad-hoc register allocator
- X86 backend
- example that evolved fro= m LLVM kaleidoscope ported to DragonKit to Pascal/ML like language, and ano= ther example using direct translation to X86 backend.

The code is functorised and almost purely functional (with few exceptio= ns where there is no benefit of doing that).

Maybe it could have som= e use in your new toplevel, or maybe it would be worth to reuse some of you= r work in DragonKit (or viceversa).

I welcome anybody wanting to join me in this effort.

Please take= a look at:

www.g= ithub.com/danmey/DragonKit

Cheers;
Wojciech


greets= ,
Benedikt


[1] http://portal.acm.org/citation.cfm?id=3D330250
[2] http://caml.inria.fr= /pub/ml-archives/caml-list/2010/11/a1b0ed0934ff51df4ac07c5e9da6e9d6.en.html=


--
Caml-list mailing list. =A0Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--000e0cd39c88b7979704a9734b56--