From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 96FD5800AD for ; Thu, 22 Dec 2016 17:15:38 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f181.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.181 as permitted sender) identity=mailfrom; client-ip=209.85.223.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io0-f181.google.com) identity=helo; client-ip=209.85.223.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f181.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AZvM/EREl7iJUPnxL3fQHnZ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ75pcqwAkXT6L1XgUPTWs2DsrQf2rGQ4/yrCTdIoc7Y9itdINoUD15NoP?= =?us-ascii?q?5VtjJjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9?= =?us-ascii?q?fbytScb6xv663OGq+pDVfx4AxH/kOeszf12KqlD8qMYbh5oqEKEswBrPqXtUdu?= =?us-ascii?q?VQjTd6JV+Vjh+lvp/v1JFm+iVU/fkm8pgTf7/9evEXRLZCDTkie1s+5MDxuAOL?= =?us-ascii?q?GQSG7GEdX2FQiRFIDhLI9jn1W57wtm3xse8ri3rSBtH/Ub1hAWfq1KxsUhK9zX?= =?us-ascii?q?5fbzM=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQAu+1tYhrXfVdFeFgMBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBARQBAQEBAQEBAQEBAQcBAQEBAYMKAQEBAQF8eRAHhEmfU5UVggk?= =?us-ascii?q?qhXgCgWUHQRIBAQEBAQEBAQEBARIBAQEICwsJHTCCMwQBFQEEghYBAQECAQEjH?= =?us-ascii?q?QEbHQEDAQsGBQsDCioCAiEBAREBBQEcBhOIUQEDEAgOnT8/jAKCBAUBHoMMBYN?= =?us-ascii?q?fChknDVSCaQEBAQEBBQEBAQEBAQEBGAIGEoY2hGOCUoImgh84gl0FkAGKQzWBe?= =?us-ascii?q?oRYhnCDeIF1UYQ2iVaFQIQthDmCSRQegRQPFwaBMlESgxssIIIGIDQBhxmBTwE?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A0BSAQAu+1tYhrXfVdFeFgMBAQEBAQEBAQEBAQcBAQEBARQ?= =?us-ascii?q?BAQEBAQEBAQEBAQcBAQEBAYMKAQEBAQF8eRAHhEmfU5UVggkqhXgCgWUHQRIBA?= =?us-ascii?q?QEBAQEBAQEBARIBAQEICwsJHTCCMwQBFQEEghYBAQECAQEjHQEbHQEDAQsGBQs?= =?us-ascii?q?DCioCAiEBAREBBQEcBhOIUQEDEAgOnT8/jAKCBAUBHoMMBYNfChknDVSCaQEBA?= =?us-ascii?q?QEBBQEBAQEBAQEBGAIGEoY2hGOCUoImgh84gl0FkAGKQzWBeoRYhnCDeIF1UYQ?= =?us-ascii?q?2iVaFQIQthDmCSRQegRQPFwaBMlESgxssIIIGIDQBhxmBTwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,389,1477954800"; d="scan'208,217";a="251233447" Received: from mail-io0-f181.google.com ([209.85.223.181]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Dec 2016 17:15:37 +0100 Received: by mail-io0-f181.google.com with SMTP id m133so49884679iom.3 for ; Thu, 22 Dec 2016 08:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NwtewsDqBbtRMZ5ubGuJz5FkUAC5oIEw83AY6JA7MDA=; b=TH3BUqbAaSS2hs9TlHWeNughGyd2yhqQKQ0b8pVl/A6NZKNbaCp+XYst8enYWjZntD 9d0B/i2+2Hzj1d2jmS7k/LJ3wdUAJgJcAoJeqVZIt0kshQhpMmiB9GrniX3d8N6Kvm/l VFcXX5FvdCWAH+Kignp5Ngn+Pda0AkMKDL+aRqCLsUyqKiab1Q5H33jd5EgkkU4Z6L01 3u/Dxq/0Gf+rDm3imq0jrUfL/zSqC+44nL2w8yaVf4SHpzYvxJhCHk87K3J9j+TWk/Of DI1/Dkj4FVOKb0E8N4pUMKZa4xmpjtP9XrENDQV4EaZwPI3yv0mrF1doIcxFxYEN3mwW u1QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NwtewsDqBbtRMZ5ubGuJz5FkUAC5oIEw83AY6JA7MDA=; b=MUpCzqgZ3yrTKLzNs/+T+Iy4erxcMHEZnhYmYAArYN448LYMneK05wI4VCrdCzerBp oR3jGVoBEhGCFYfPGN8f7z/CNbP531KPNwkJDv63mFmm9llmEBYJ8S0m9IPIa1uZ1yrp sEzPpccyXuV2AtKcCYyjMFNV6KINnDBodvHzlcVYdgvQA/bX1106Bzg7NpXPsXPG7rnf oNvJDloHCRO/NpGoK1FPQzJL/2zJIGyS7LUovqRw1ZYsFVkpUp/oGv/XpGG5GVHnRtFr No/aWaEHAiKNaBbGpIERDvAq5zDxQjMbde8r5j6lxSjpwSJFB5dUXnfV6gupe4Rgu1rl QwVA== X-Gm-Message-State: AIkVDXKlHpBjBwTmoODQ6PkGp1bGRADbrhAuKoBLyAx0eevsZifP0P0hBnF8AfbIood9HJ98SDl5+RJsuDQ9rQ== X-Received: by 10.107.164.159 with SMTP id d31mr7536062ioj.182.1482423336031; Thu, 22 Dec 2016 08:15:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.140.195 with HTTP; Thu, 22 Dec 2016 08:14:55 -0800 (PST) In-Reply-To: References: <20161222011231.GA26221@topoi.pooq.com> From: Gabriel Scherer Date: Thu, 22 Dec 2016 11:14:55 -0500 Message-ID: To: Evgeny Roubinchtein Cc: Hendrik Boom , caml users Content-Type: multipart/alternative; boundary=001a11378bb459da5005444194b3 Subject: Re: [Caml-list] off-brand use of ocaml bytecode --001a11378bb459da5005444194b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is one known case of the OCaml runtime being reused, namely the Coq bytecode interpreter, which is a modified version of the OCaml bytecode interpreter that supports a different evaluation strategy. This is described in the article A Compiled Implementation of Strong Reduction Benjamin Gr=C3=A9goire and Xavier Leroy, 2002 http://gallium.inria.fr/~xleroy/publi/strong-reduction.pdf This implementation duplicates (and simplifies) the instruction set and interpretation loop, but it does reuse the same value representation and, I believe, the OCaml runtime system (the GC in particular). If you are interested in a documentation of the OCaml bytecode runtime, the two following documents could be of help: - Benedikt Meurer's article on his work on jitting the bytecode runtime begins with a very clear how-level description of how the whole thing works in OCaml today: https://arxiv.org/abs/1011.1783 - Xavier Clerc, while working on OCamlJava, produced a very detailed and up-to-date reference of the OCaml bytecode instruction set ( http://cadmium.x9c.fr/distrib/caml-instructions.pdf ) (A more high-level description of the principles behind the instruction set, in particular how it makes curried functions fast enough, can be found in Xavier Leroy's course notes on "abstract machines and compilation", along with comparisons with other designs of the 80s or early 90s and some correctness proofs: http://gallium.inria.fr/~xleroy/mpri/2-4/machines.pdf ) On Thu, Dec 22, 2016 at 10:48 AM, Evgeny Roubinchtein wrote: > I know there are people on this list who are way more qualified to answer > these questions, but let me try. > > On Wed, Dec 21, 2016 at 8:12 PM, Hendrik Boom > wrote: > >> Are there ny tools available that could be used to generate ocaml >> bytecode for other languages? >> > > I don't think you will get a definitive answer on this list. Here is a > thought experiment showing why. Suppose J. Random Hacker decides to write > a compiler from WhizBangLang to OCaml byte code. Under the assumption th= at > OCaml developers are not omniscient, the way they would learn about J. > Random Hacker's efforts is if s/he either: a) announces the new language = in > some venue that OCaml developers watch or b) finds [what s/he believes ar= e] > bugs in the OCaml byte code interpreter and files bug reports against it. > It isn't clear to me that our J Random Hacker must needs do either of tho= se > things. > > If I were to do that, by hand or otherwise, how would I interpret or >> compile it? >> > > The ocamlrun program, shipped with the OCaml distribution and documented > at http://caml.inria.fr/pub/docs/manual-ocaml/runtime.html is the > standard interpreter for the OCaml byte code. > > For the OCaml compiler, the byte code is a target (as opposed to a source > or an intermediate representation), so the existing OCaml tool chain does > not support compiling byte code, to the best of my knowledge (AFAIK > projects like Bucklescript and js_of_ocaml use the OCaml front-end and > intermediate representation, but supply a different compiler back end). > > Would the ocaml run-time system we available -- things like the garbage >> collector, I/O libraries, etc. >> > > I think that question is answered in the documentation of ocamlrun. You > probably will also want to peruse http://caml.inria.fr/ > pub/docs/manual-ocaml/intfc.html and specifically the discussion of > static and dynamic linking of C code with OCaml code. > > >> Is anyone else working of projects like this? > > > I am not entirely certain what the intended antecedent of "this" is here. > If "this" is "a compiler that targets OCaml byte code", then please see my > answer above. If you feel that the current design of "ocamlrun for > standard primitives + the '-custom' flag to the OCaml compiler for > non-standard primitives" is failing to address a need, then a description > of the need that isn't being addressed would be a good starting point for > discussion. ;-) > > Hope this helps > -- > Best, > Zhenya > > --001a11378bb459da5005444194b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is one known case of the OCaml runtime being re= used, namely the Coq bytecode interpreter, which is a modified version of t= he OCaml bytecode interpreter that supports a different evaluation strategy= . This is described in the article

=C2=A0 A Compiled Implementation = of Strong Reduction
=C2=A0 Benjamin Gr=C3=A9goire and Xavier Leroy= , 2002
This implementation duplicates (and simplifi= es) the instruction set and interpretation loop, but it does reuse the same= value representation and, I believe, the OCaml runtime system (the GC in p= articular).

If you are interested in a documentation of t= he OCaml bytecode runtime, the two following documents could be of help:
- Benedikt Meurer's article on his work on jitting the byte= code runtime begins with a very clear how-level description of how the whol= e thing works in OCaml today: h= ttps://arxiv.org/abs/1011.1783
- Xavier Clerc, while work= ing on OCamlJava, produced a very detailed and up-to-date reference of the = OCaml bytecode instruction set ( http://cadmium.x9c.fr/distrib/caml-instructions.pdf )


On Thu, Dec 22, 2016 at 10:48 = AM, Evgeny Roubinchtein <zhenya1007@gmail.com> wrote:
=
= I know there are people on this list who are way more qualified to answer t= hese questions, but let me try.

On Wed, Dec 21, 2016 at 8:12 PM, Hendr= ik Boom <hendrik@topoi.pooq.com> wrote:
Are there ny tools available that cou= ld be used to generate ocaml
bytecode for other languages?

I = don't think you will get a definitive answer on this list. =C2=A0 Here = is a thought experiment showing why.=C2=A0 Suppose J. Random Hacker decides= to write a compiler from WhizBangLang to OCaml byte code.=C2=A0 Under the = assumption that OCaml developers are not omniscient, the way they would lea= rn about J. Random Hacker's efforts is if s/he either: a) announces the= new language in some venue that OCaml developers watch or b) finds [what s= /he believes are] bugs in the OCaml byte code interpreter and files bug rep= orts against it.=C2=A0 It isn't clear to me that our J Random Hacker mu= st needs do either of those things.

If I were to do that, by ha= nd or otherwise, how would I interpret or
compile it?

The ocamlrun program= , shipped with the OCaml distribution and documented at http://c= aml.inria.fr/pub/docs/manual-ocaml/runtime.html is the standard in= terpreter for the OCaml byte code.=C2=A0

For the O= Caml compiler, the byte code is a target (as opposed to a source or an inte= rmediate representation), so the existing OCaml tool chain does not support= compiling byte code, to the best of my knowledge (AFAIK projects like Buck= lescript and js_of_ocaml use the OCaml front-end and intermediate represent= ation, but supply a different compiler back end).

Would the ocaml run-time system we available -- things like the garbage
collector, I/O libraries, etc.

I= think that question is answered in the documentation of ocamlrun. =C2=A0 Y= ou probably will also want to peruse=C2=A0http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html and specifically the discussion= of static and dynamic linking of C code with OCaml code.
=C2=A0
Is anyone else working of projects like this?

I am not entirely certain what the intended antecedent of "t= his" is here.=C2=A0 If "this" is "a compiler that targe= ts OCaml byte code", then please see my answer above.=C2=A0 If you fee= l that the current design of "ocamlrun for standard primitives + the &= #39;-custom' flag to the OCaml compiler for non-standard primitives&quo= t; is failing to address a need, then a description of the need that isn= 9;t being addressed would be a good starting point for discussion. ;-)

Hope this helps
--=C2=A0
Best,
Zhenya


--001a11378bb459da5005444194b3--