Previous Contents Next

Compilation

The distribution of a language depends on the processor and the operating system. For each architecture, a distribution of Objective CAML contains the toplevel system, the bytecode compiler, and in most cases a native compiler.

Command Names

The figure 7.5 shows the command names of the different compilers in the various Objective CAML distributions. The first four commands are available for all distributions.


ocaml toplevel loop
ocamlrun bytecode interpreter
ocamlc bytecode batch compiler
ocamlopt native code batch compiler
ocamlc.opt optimized bytecode batch compiler
ocamlopt.opt optimized native code batch compiler
ocamlmktop new toplevel constructor

Figure 7.5: Commands for compiling.


The optimized compilers are themselves compiled with the Objective CAML native compiler. They compile faster but are otherwise identical to their unoptimized counterparts.

Compilation Unit

A compilation unit corresponds to the smallest piece of an Objective CAML program that can be compiled. For the interactive system, the unit of compilation corresponds to a phrase of the language. For the batch compiler, the unit of compilation is two files: the source file, and the interface file. The interface file is optional - if it does not exist, then all global declarations in the source file will be visible to other compilation units. The construction of interface files is described in the chapter on module programming (14). The two file types (source and interface) are differentiated by separate file extensions.

Naming Rules for File Extensions

Figure 7.6 presents the extensions of different files used for Objective CAML and C programs.


extension meaning
.ml source file
.mli interface file
.cmo object file (bytecode)
.cma library object file (bytecode)
.cmi compiled interface file
.cmx object file (native)
.cmxa library object file (native)
.c C source file
.o C object file (native)
.a C library object file (native)

Figure 7.6: File extensions.


The files example.ml and example.mli form a compilation unit. The compiled interface file (example.cmi) is used for both the bytecode and native code compiler. The C language related files are used when integrating C code with Objective CAML code. (12).

The Bytecode Compiler

The general form of the batch compiler commands are:

command options file_name

For example:
ocamlc -c example.ml
The command-line options for both the native and bytecode compilers follow typical Unix conventions. Each option is prefixed by the character -. File extensions are interpreted in the manner described by figure 7.6. In the above example, the file example.ml is considered an Objective CAML source file and is compiled. The compiler will produce the files example.cmo and example.cmi. The option -c informs the compiler to generate individual object files, which may be linked at a later time. Without this option, the compiler will produce an executable file named a.out.

The table in figure 7.7 describes the principal options of the bytecode compiler. The table in figure 7.8 indicates other possible options.

Principal options
-a construct a runtime library
-c compile without linking
-o name_of_executable specify the name of the executable
-linkall link with all libraries used
-i display all compiled global declarations
-pp command uses command as preprocessor
-unsafe turn off index checking
-v display the version of the compiler
-w list choose among the list the level of warning message (see fig. 7.9)
-impl file indicate that file is a Caml source (.ml)
-intf file indicate that file is a Caml interface (.mli)
-I directory add directory in the list of directories

Figure 7.7: Principal options of the bytecode compiler.



Other options
light process -thread (19, page ??)
linking -g, -noassert (10, page ??)
standalone executable -custom, -cclib, -ccopt, -cc (see page ??)
runtime -make-runtime , -use-runtime
C interface -output-obj (12, page ??)

Figure 7.8: Other options for the bytecode compiler.


To display the list of bytecode compiler options, use the option -help.

The different levels of warning message are described in figure 7.9. A message level is a switch (enable/disable) represented by a letter. An upper case letter activates the level and a lower case letter disables it.

Principal levels  
A/a enable/disable all messages
F/f partial application in a sequence
P/p for incomplete pattern matching
U/u for missing cases in pattern matching
X/x enable/disable all other messages
for hidden object M/m and V/v (see chapter 15)

Figure 7.9: Description of compilation warnings.


By default, the highest level (A) is chosen by the compiler.

Example usage of the bytecode compiler is given in figure 7.10.



Figure 7.10: Session with the bytecode compiler.


Native Compiler

The native compiler has behavior similar to the bytecode compiler, but produces different types of files. The compilation options are generally the same as those described in figures 7.7 and 7.8. It is necessary to take out the options related to runtime in figure 7.8. Options specific to the native compiler are given in figure 7.11. The different warning levels are same.

-compact optimize the produced code for space
-S keeps the assembly code in a file
-inline level set the aggressiveness of inlining

Figure 7.11: Options specific to the native compiler.


Inlining is an elaborated version of macro-expansion in the preprocessing stage. For functions whose arguments are fixed, inlining replaces each function call with the body of the function called. Several different calls produce several copies of the function body. Inlining avoids the overhead that comes with function call setup and return, at the expense of object code size. Principal inlining levels are:

Toplevel Loop

The toplevel loop provides only two command line options. The toplevel loop provides several directives which can be used to interactively modify its behavior. They are described in figure 7.12. All these directives begin with the character # and are terminated by ;;.

#quit ;; quit from the toplevel interaction
#directory directory ;; add the directory to the search path
#cd directory ;; change the working directory
#load object_file ;; load an object file (.cmo)
#use source_file ;; compile and load a source file
#print_depth depth ;; modify the depth of printing
#print_length width ;; modify the length of printing
#install_printer function ;; specify a printing function
#remove_printer function ;; remove a printing function
#trace function ;; trace the arguments of the function
#untrace function ;; stop tracing the function
#untrace_all ;; stop all tracing

Figure 7.12: Toplevel loop directives.


The directives dealing with directories respect the conventions of the operating system used.

The loading directives do not have exactly the same behavior. The directive #use reads the source file as if it was typed directly in the toplevel loop. The directive #load loads the file with the extension .cmo. In the later case, the global declarations of this file are not directly accessible. If the file example.ml contains the global declaration f, then once the bytecode is loaded (#load "example.cmo";;), it is assumed that the value of f could be accessed by Example.f, where the first letter of the file is capitalized. This notation comes from the module system of Objective CAML (see chapter 14, page ??).

The directives for the depth and width of printing are used to control the display of values. This is useful when it is necessary to display the contents of a value in detail.

The directives for printer redefinition are used to install or remove a user defined printing function for values of a specified type. In order to integrate these printer functions into the default printing procedure, it is necessary to use the Format library(8) for the definition.

The directives for tracing arguments and results of functions are particularly useful for debugging programs. They will be discussed in the chapter on program analysis (10).

Figure 7.13 shows a session in the toplevel loop.



Figure 7.13: Session with the toplevel loop.


Construction of a New Interactive System

The command ocamlmktop can be used to construct a new toplevel executable which has specific library modules loaded by default. For example, ocamlmktop is often used for pulling native object code libraries (typically written in C) into a new toplevel.

ocamlmktop options are a subset of those used by the bytecode compiler (ocamlc):
-cclib libname, -ccopt option, -custom, -I directory -o executable_name
The chapter on graphics programming (5, page ??) uses this command for constructing a toplevel system containing the Graphics library in the following manner:
ocamlmktop -custom -o mytoplevel graphics.cma -cclib \ 
           -I/usr/X11/lib -cclib -lX11
This command constructs an executable with the name mytoplevel, containing the bytecode library graphics.cma. This standalone executable (-custom, see the following section) will be linked to the library X11 (libX11.a) which in turn will be looked up in the path /usr/X11/lib.


Previous Contents Next