CompilationThe distribution of a language depends on the processor and the operating
system. For each
architecture, a distribution of
contains the toplevel system, the bytecode compiler, and in most cases a native compiler.
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.
The optimized compilers are themselves compiled with the Objective CAML native compiler. They compile faster but are otherwise identical to their unoptimized counterparts.
||bytecode batch compiler
||native code batch compiler
||optimized bytecode batch compiler
||optimized native code batch compiler
||new toplevel constructor
Figure 7.5: Commands for compiling.
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.
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.
||object file (bytecode)
||library object file (bytecode)
||compiled interface file
||object file (native)
||library object file (native)
||C source file
||C object file (native)
||C library object file (native)
Figure 7.6: File extensions.
The Bytecode Compiler
The general form of the batch compiler commands are:
command options file_name
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
The table in figure 7.7 describes the principal options of the bytecode compiler. The table in figure 7.8 indicates other possible options.
||construct a runtime library
||compile without linking
||specify the name of the executable
||link with all libraries used
||display all compiled global declarations
||uses command as preprocessor
||turn off index checking
||display the version of the compiler
||choose among the list the level of warning message
(see fig. 7.9)
||indicate that file is a Caml source (.ml)
||indicate that file is a Caml interface (.mli)
||add directory in the list of directories
Figure 7.7: Principal options of the bytecode compiler.
To display the list of bytecode compiler options, use the option -help.
||-thread (19, page ??)
(10, page ??)
||-custom, -cclib, -ccopt, -cc
(see page ??)
||-make-runtime , -use-runtime
(12, page ??)
Figure 7.8: Other options for the bytecode compiler.
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.
By default, the highest level (A) is chosen by the compiler.
||enable/disable all messages
||partial application in a sequence
||for incomplete pattern matching
||for missing cases in pattern matching
||enable/disable all other messages
|for hidden object
||M/m and V/v (see chapter 15)
Figure 7.9: Description of compilation warnings.
Example usage of the bytecode compiler is given in figure 7.10.
Figure 7.10: Session with the bytecode 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.
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:
||optimize the produced code for space
||keeps the assembly code in a file
||set the aggressiveness of inlining
Figure 7.11: Options specific to the native compiler.
0 : The expansion will be done only when it will not increase the size of the object code.
- 1 : This is the default value; it accepts a light increase on code size.
- n>1 : Raise the tolerance for growth in the code. Higher values result in more inlining.
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
-I directory: adds the indicated directory to the list of
search paths for compiled source files.
- -unsafe: instructs the compiler not to do bounds checking on
array and string accesses.
are terminated by
The directives dealing with directories respect the conventions of the operating
|quit from the toplevel interaction
|add the directory to the search path
|change the working directory
|load an object file (.cmo)
|compile and load a source file
|modify the depth of printing
|modify the length of printing
|specify a printing function
|remove a printing function
|trace the arguments of the function
|stop tracing the function
|stop all tracing
Figure 7.12: Toplevel loop directives.
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
#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):
The chapter on graphics programming (5, page ??) uses this command for constructing a toplevel system containing the Graphics
library in the following manner:
|-cclib libname, -ccopt option, -custom,
-I directory -o executable_name
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.