Re: [Caml-list] OCamlPro Highlights: Dec 2013 & Jan 2014

[Alain Frisch <alain@frisch.fr>]

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