diff6-10.chapter11.txt

このページは最後に更新されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

last mod. 2008-08-28 (木) 09:53:20

diff6-10

 12,13c12,13
 <   It is not possible to mix native-code object files produced by ocamlc with
 < bytecode object files produced by ocamlopt: a program must be compiled entirely
 ---
 >   It is not possible to mix native-code object files produced by ocamlopt with
 > bytecode object files produced by ocamlc: a program must be compiled entirely
 23c23,24
 < ocamlc. It accepts the same types of arguments:
 ---
 > ocamlc. It accepts the same types of arguments, and processes them
 > sequentially:
 70,71c71,72
 <   The output of the linking phase is a regular Unix executable file. It does
 < not need ocamlrun to run.
 ---
 >   The output of the linking phase is a regular Unix or Windows executable file.
 > It does not need ocamlrun to run.
 80a82
 >  
 107a110,125
 >  -dtypes  Dump detailed type information. The information for file x.ml is put
 >    into file x.annot. In case of a type error, dump all the information
 >    inferred by the type-checker before the error. The x.annot file can be used
 >    with the emacs commands given in emacs/caml-types.el to display types
 >    interactively.
 >  
 >  -for-pack module-path  Generate an object file (.cmx/.o file) that can later
 >    be included as a sub-module (with the given access path) of a compilation
 >    unit constructed with -pack. For instance, ocamlopt -for-pack P -c A.ml will
 >    generate a.cmx and a.o files that can later be used with ocamlopt -pack -o
 >    P.cmx a.cmx.
 >  
 >  -g  Add debugging information while compiling and linking. This option is
 >    required in order to produce stack backtraces when the program terminates on
 >    an uncaught exception (see section 10.2).
 >  
 109,114c127,133
 <    or their definitions) when compiling an implementation (.ml file). This can
 <    be useful to check the types inferred by the compiler. Also, since the
 <    output follows the syntax of interfaces, it can help in writing an explicit
 <    interface (.mli file) for a file: just redirect the standard output of the
 <    compiler to a .mli file, and edit that file to remove all declarations of
 <    unexported names.
 ---
 >    or their definitions) when compiling an implementation (.ml file). No
 >    compiled files (.cmo and .cmi files) are produced. This can be useful to
 >    check the types inferred by the compiler. Also, since the output follows the
 >    syntax of interfaces, it can help in writing an explicit interface (.mli
 >    file) for a file: just redirect the standard output of the compiler to a
 >    .mli file, and edit that file to remove all declarations of unexported
 >    names.
 155,157c174,178
 <    default output name is a.out, in keeping with the Unix tradition. If the -a
 <    option is given, specify the name of the library produced. If the
 <    -output-obj option is given, specify the name of the output file produced.
 ---
 >    default output name is a.out under Unix and camlprog.exe under Windows. If
 >    the -a option is given, specify the name of the library produced. If the
 >    -pack option is given, specify the name of the packed object file produced.
 >    If the -output-obj option is given, specify the name of the output file
 >    produced.
 171,177c192,197
 <                    See the Unix manual page for gprof(1) for more information
 <                   about the profiles.
 <                   Full support for gprof is only available for certain
 <                   platforms (currently: Intel x86/Linux and Alpha/Digital
 <                   Unix). On other platforms, the -p option will result in a
 <                   less precise profile (no call graph information, only a time
 <                   profile). 
 ---
 >        See the Unix manual page for gprof(1) for more information about the
 >       profiles.
 >       Full support for gprof is only available for certain platforms
 >       (currently: Intel x86/Linux and Alpha/Digital Unix). On other platforms,
 >       the -p option will result in a less precise profile (no call graph
 >       information, only a time profile). 
 187,188c207
 <    <<
 <              ocamlopt -pack -o p.cmx a.cmx b.cmx c.cmx
 ---
 >    <<        ocamlopt -pack -o P.cmx A.cmx B.cmx C.cmx
 190c209
 <  generates compiled files p.cmx, p.o and p.cmi describing a compilation unit
 ---
 >  generates compiled files P.cmx, P.o and P.cmi describing a compilation unit
 192c211
 <    object files a.cmx, b.cmx and c.cmx. These contents can be referenced as
 ---
 >    object files A.cmx, B.cmx and C.cmx. These contents can be referenced as
 194,197c213,223
 <     Unix: 
 <                    The -pack option is available only under platforms that
 <                   provide the GNU binutils tools nm and objcopy. 
 <  
 ---
 >  The .cmx object files being combined must have been compiled with the
 >    appropriate -for-pack option. In the example above, A.cmx, B.cmx and C.cmx
 >    must have been compiled with ocamlopt -for-pack P.
 >  Multiple levels of packing can be achieved by combining -pack with -for-pack.
 >    Consider the following example: 
 >    <<        ocamlopt -for-pack P.Q -c A.ml
 >              ocamlopt -pack -o Q.cmx -for-pack P A.cmx
 >              ocamlopt -for-pack P -c B.ml
 >              ocamlopt -pack -o P.cmx Q.cmx B.cmx
 >    >>
 >  The resulting P.cmx object file has sub-modules P.Q, P.Q.A and P.B.
 213c239,240
 <    supported.
 ---
 >    supported. Note that once you have created an interface using this flag, you
 >    must use it again for all dependencies.
 219,220c246
 <    threads library described in chapter 24. What this option actually does is
 <    select a special, thread-safe version of the standard library.
 ---
 >    system threads library described in chapter 24.
 225c251,254
 <    outside of its bounds.
 ---
 >    outside of its bounds. Additionally, turn off the check for zero divisor in
 >    integer division and modulus operations. With -unsafe, an integer division
 >    (or modulus) by zero can halt the program or continue with an unspecified
 >    result instead of raising a Division_by_zero exception.
 242a272,274
 >     E/e  enable/disable warnings for fragile pattern matchings (matchings that
 >       would remain complete if additional constructors are added to a variant
 >       type involved). 
 252a285,288
 >     Y/y  enable/disable warnings for unused variables bound with the let or as
 >       keywords and that don't start with an underscore. 
 >     Z/z  enable/disable warnings for all unused variables that don't start with
 >       an underscore. 
 254c290,291
 <   The default setting is -w Al (all warnings but labels enabled).
 ---
 >   The default setting is -w Aelyz (all warnings enabled except fragile
 >    matchings, omitted labels, unused variables).
 265a303,322
 > Options for the IA32 architecture
 >    The IA32 code generator (Intel Pentium, AMD Athlon) supports the following
 > additional option:
 >   
 >   
 >  -ffast-math  Use the IA32 instructions to compute trigonometric and
 >    exponential functions, instead of calling the corresponding library
 >    routines. The functions affected are: atan, atan2, cos, log, log10, sin,
 >    sqrt, and tan. The resulting code runs faster, but the range of supported
 >    arguments and the precision of the result can be reduced. In particular,
 >    trigonometric operations cos, sin, tan have their range reduced to [-2^64,
 >    2^64]. 
 >   
 > Options for the Sparc architecture
 >    The Sparc code generator supports the following additional options: 
 >   
 >  -march=v8  Generate SPARC version 8 code. 
 >  -march=v9  Generate SPARC version 9 code. 
 >    The default is to generate code for SPARC version 7, which runs on all SPARC
 > processors.
 275c332,352
 < 11.4  Compatibility with the bytecode compiler
 ---
 > 11.4  Running executables produced by ocamlopt
 > *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 > 
 >   
 >   Executables generated by ocamlopt are native, statically-linked, stand-alone
 > executable files that can be invoked directly. They do not depend on the
 > ocamlrun bytecode runtime system.
 >   During execution of an ocamlopt-generated executable, the following
 > environment variables are also consulted: 
 >   
 >  OCAMLRUNPARAM  Same usage as in ocamlrun (see section 10.2), except that
 >    option l is ignored (the operating system's stack size limit is used
 >    instead) and option b is ignored (stack backtraces on uncaught exceptions
 >    are not printed). 
 >  CAMLRUNPARAM  If OCAMLRUNPARAM is not found in the environment, then
 >    CAMLRUNPARAM will be used instead. If CAMLRUNPARAM is not found, then the
 >    default values will be used. 
 >   
 >   
 > 
 > 11.5  Compatibility with the bytecode compiler
 284,294d360
 <  - The following operations abort the program (via an hardware trap or fatal
 <    Unix signal) instead of raising an exception: 
 <      
 <     - integer division by zero, modulus by zero; 
 <     - stack overflow; 
 <     - on the Alpha processor only, floating-point operations involving infinite
 <       or denormalized numbers (all other processors supported by ocamlopt treat
 <       these numbers correctly, as per the IEEE 754 standard). 
 <   In particular, notice that stack overflow caused by excessively deep
 <    recursion is reported by most Unix kernels as a ``segmentation violation''
 <    signal.
 300,304c366,388
 <   The best way to avoid running into those incompatibilities is to never trap
 < the Division_by_zero and Stack_overflow exceptions, thus also treating them as
 < fatal errors with the bytecode compiler as well as with the native-code
 < compiler. Often, it is feasible to test the divisor before performing the
 < operation, instead of trapping the exception afterwards.  
 ---
 >  - Stack overflow, typically caused by excessively deep recursion,  is handled
 >    in one of the following ways, depending on the platform used: 
 >      
 >     - By raising a Stack_overflow exception, like the bytecode compiler does.
 >       (IA32/Linux, AMD64/Linux, PowerPC/MacOSX, MS Windows 32-bit ports). 
 >     - By aborting the program on a "segmentation fault" signal. (All other Unix
 >       systems.) 
 >     - By terminating the program silently. (MS Windows 64 bits). 
 >  
 >  
 >  - On IA32 processors only (Intel Pentium, AMD Athlon, etc, in 32-bit mode),
 >    some intermediate results in floating-point computations are kept in
 >    extended precision rather than being rounded to double precision like the
 >    bytecode compiler always does. Floating-point results can therefore differ
 >    between bytecode and native code; in general, the results obtained with
 >    native code are "more exact" (less affected by rounding errors and loss of
 >    precision).
 >  
 >  - On the Alpha processor only, floating-point operations involving infinite or
 >    denormalized numbers can abort the program on a "floating-point exception"
 >    signal.
 >   
 >

新規 編集 添付