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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 915BA7F7C2 for ; Fri, 7 Feb 2014 10:15:31 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.210; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.210; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.210; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAKuj9FLB/BfSnGdsb2JhbABYwBSDBoEgDgEBAQEBCAsJCRQogiUBAQUyAQVAARALGAkMCg8JAwIBAgE3AQ0GAQwBBwEBiAXNGheOfQcKhC4BA5grhkiPBw X-IPAS-Result: AsIBAKuj9FLB/BfSnGdsb2JhbABYwBSDBoEgDgEBAQEBCAsJCRQogiUBAQUyAQVAARALGAkMCg8JAwIBAgE3AQ0GAQwBBwEBiAXNGheOfQcKhC4BA5grhkiPBw X-IronPort-AV: E=Sophos;i="4.95,799,1384297200"; d="scan'208";a="48135497" Received: from msa01.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.210]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2014 10:15:31 +0100 Received: from [192.168.1.133] ([92.151.71.198]) by mwinf5d37 with ME id PMFV1n00R4Ggq9Y03MFV2K; Fri, 07 Feb 2014 10:15:30 +0100 Message-ID: <52F4A432.4010209@frisch.fr> Date: Fri, 07 Feb 2014 10:15:30 +0100 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?windows-1252?Q?Pierre-=C9tienne_Meunier?= , Fabrice Le Fessant CC: Ocaml Mailing List References: <92F45A7B-CC6A-45B6-86CF-DBC3C87A5D59@gmail.com> In-Reply-To: <92F45A7B-CC6A-45B6-86CF-DBC3C87A5D59@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014 On 02/06/2014 11:53 AM, Pierre-Étienne Meunier wrote: > However, what is the difference between new backends, and using llvm? Since this work is done by OCamlPro on behalf of LexiFi, let me answer this one. This current project is much less ambitious than switching to llvm. Some context: ocamlopt generates machine code by producing some textual assembly code and calling an external assembler (gas or masm) to produce object files. The assembly code is produced directly from an higher-level intermediate representation defined in asmcomp/linearize.mli (which represents a list of pseudo-instructions). The mapping from this representation to assembly language contains some logic such as picking concrete opcodes (including special cases such as a simplified jump for a self tail-call), maintaining the current stack offset, taking into account various compilation mode (debug mode, fast/compact mode, pic mode), expanding complex pseudo-instructions into several actual assembly opcodes (e.g. to compile switches using jump tables), sharing floating point literals, etc. Since two concrete syntaxes of assembly languages (gas/masm) have to be supported, this mapping has to be implemented twice for each CPU (amd64/emit.mlp + amd64/emit_nt.mlp, and same for i386/), which adds burden when this code evolves (and it still does quite often). So the project is to add an extra intermediate language between linearize.mli and textual assembly language. This new representation can be seen as a symbolic representation of machine code or an AST of the generated assembly language. This will allow to share most code from emit.mlp and emit_nt.mlp. Two "printers" from this new representation to source assembly language will be implemented. In addition to reducing the maintenance overhead and reducing the risk of having the Windows port lagging behind, this will bring a few more advantages: - It will be quite easy to have a third "printer", which generates direct binary machine code instead of source assembly language. LexiFi already uses such binary backends for x86 and amd64, which (together with a COFF object emitter) make it possible to have a version of ocamlopt under Windows that does not require an external assembler. (And this allows our end-user application to compile source OCaml code and dynlink it on the fly, without forcing our customers to install any toolchain.) The new project will greatly facilitate the maintenance of these direct binary backends (and this is actually LexiFi's primary reason for funding this project). The same backends would actually be of interest to other projects, such as the native toplevel or MetaOCaml. - Some low-level optimizations could be performed on the new representation (typically, peep-hole optimizations). - The project will probably make it easier to maintain or experiment with new variants of the backends (I'm thinking about the ia32 port from the sse2 branch, i.e. a variant of x86 using sse2 instructions for floating point arithmetic instead of x87 instructions). Alain