From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3031FBC6B for ; Fri, 12 Oct 2007 16:59:58 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALUnD0dA6ba6kGdsb2JhbACOTgIBAQcCBiQH X-IronPort-AV: E=Sophos;i="4.21,267,1188770400"; d="scan'208";a="17916158" Received: from nf-out-0910.google.com ([64.233.182.186]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Oct 2007 16:59:57 +0200 Received: by nf-out-0910.google.com with SMTP id e27so732081nfd for ; Fri, 12 Oct 2007 07:59:57 -0700 (PDT) Received: by 10.86.51.2 with SMTP id y2mr2437718fgy.1192201197168; Fri, 12 Oct 2007 07:59:57 -0700 (PDT) Received: by 10.86.61.18 with HTTP; Fri, 12 Oct 2007 07:59:57 -0700 (PDT) Message-ID: <89aa9c440710120759v5812727ex82359b27c399cccf@mail.gmail.com> Date: Fri, 12 Oct 2007 16:59:57 +0200 From: "Massimiliano Brocchini" To: "Caml mailing list" Subject: Request for information on the compiler internals MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: no; 0.00; compiler:01 ocaml:01 compiler:01 lexing:01 dependencies:01 ocamldoc:01 ocamlopt:01 pointers:01 asmcomp:01 asmcomp:01 symlinks:01 foo:01 foo:01 ocamlopt:01 ocamlc:01 Hi, I've been looking for information on OCaml compiler internals during this w= eek. Gordon's reply is a nice starting point, but is there any documentation on the compiler internals? I don't need to have a very detailed description (but it would be really interesting to study!), it would be sufficient to have access to the compiler front end i.e. lexing, parsing, name resolution (environment) and typing. A simple hint on how to use the above mentioned phases in a black box way would be nice. Thanks in advance, Massimiliano Brocchini P.S. I'm collaborating to the development of a snippet manager to facilitate libraries distribution, code reuse and to reduce binaries size by linking only the minimum amount of code your application depends on rather than the whole file (e.g. if in a toy program you use only List.map your application needs to be linked with map's code and it's dependencies not the whole List module). We already have a working prototype that uses ocamldoc, but we need to use the front end of the compiler to create a better tool. On 10/12/07, Gordon Henriksen wrote: > > On Oct 12, 2007, at 09:17, Christoph Sieghart wrote: > > Is there any documentation for adding a new architecture to ocamlopt? I > would like to do a crosscompiler from one of the existing architectures t= o > an embedded microcontroller. > > I have searched the mailinglist archives and the documenation, but have n= ot > found anything. Any pointers are welcome? Is my assumption that the major > codegeneration work is done by the code in $caml/asmcomp? > Christoph, > > > Yes, asmcomp contains both the middle-end and the back-end code generator= s. > Note that the architecture-specific features are injected by configure > creating various symlinks of the form asmcomp/.ml -> > asmcomp//.ml. On one hand, this means you should be able to cl= one > the contents of one of the asmcomp/ subdirectories and get your > project off to a start pretty quickly. On the other, ocamlopt is not a > cross-compiler, so you may have a bit of a challenge just getting the pat= hs > to the cross tools into the right places without breaking ocamlc. > I'm sure you'll get more detailed pointers, but here's a quick overview.= .. > > ocamlc and ocamlopt share code through the "Lambda" representation > (bytecomp/lambda.mli). After this point, ocamlopt transfers control into > asmcomp/asmgen.ml, which has a fairly straightforward pass pipeline in > Asmgen.compile_implementation. > > The Lambda representation is first translated into Closed Lambda > (asmcomp/clambda.mli), which is similar except that closures are explicit= . > > Next, ocamlopt transforms Clambda into its middle-end representation, C--= . > This form is somewhat well documented at http://cminusminus.org/ and in > various academic papers. The C-- representation is architecture-neutral i= n > form, but not content. Target dependencies are injected through the Arch > module, which specifies address sizes, endianness, etc. This is the point > where displacement calculations are performed, etc. > > The C-- representation is the input to the architecture-specific back-end > code generators, which are driven by the architecture-neutral > Asmgen.compile_phrase and Asmgen.compile_fundecl. In particular, this > pipeline is pleasantly self-documenting: > > let (++) x f =3D f x > > let compile_fundecl (ppf : formatter) fd_cmm =3D > Reg.reset(); > fd_cmm (* <-- The C-- representation for the function *) > ++ Selection.fundecl > ++ pass_dump_if ppf dump_selection "After instruction selection" > ++ Comballoc.fundecl > ++ pass_dump_if ppf dump_combine "After allocation combining" > ++ liveness ppf > ++ pass_dump_if ppf dump_live "Liveness analysis" > ++ Spill.fundecl > ++ liveness ppf > ++ pass_dump_if ppf dump_spill "After spilling" > ++ Split.fundecl > ++ pass_dump_if ppf dump_split "After live range splitting" > ++ liveness ppf > ++ regalloc ppf 1 > ++ Linearize.fundecl > ++ pass_dump_linear_if ppf dump_linear "Linearized code" > ++ Scheduling.fundecl > ++ pass_dump_linear_if ppf dump_scheduling "After instruction schedulin= g" > ++ Emit.fundecl > > You can identify the target-dependent phases by correlating the passes wi= th > the contents of a target subdirectory. Have fun! > > =97 Gordon > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: > http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > >