Difference between revisions of "Compile to c"

From Liberty Eiffel Wiki
Jump to navigation Jump to search
m (13 revisions: initial import from SamrtEiffel Wiki - The Grand SmartEiffel Book)
 
m
 
(15 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Book]]
+
[[Category:Tool]]
   
 
<!-- translation hint: see http://smarteiffel.loria.fr/man/compile_to_c.html -->
 
<!-- translation hint: see http://smarteiffel.loria.fr/man/compile_to_c.html -->
Line 17: Line 17:
 
In ACE mode, the name of the [[ACE]] file must end with the suffix <TT>.ace</TT>.
 
In ACE mode, the name of the [[ACE]] file must end with the suffix <TT>.ace</TT>.
   
The <TT>[[compile_to_c]]</TT> command produces the C files (<TT>*.h</TT> and <TT>*.c</TT>). A script file is also created, whose name depends on the application. This is a <TT>.make</TT> file (under UNIX) or a <TT>.BAT</TT> file (under DOS).
+
The <TT>[[compile_to_c]]</TT> command produces the C files (<TT>*.h</TT> and <TT>*.c</TT>). A script file is also created, whose name depends on the application. This is a <TT>.make</TT> file (under UNIX) or a <TT>.BAT</TT> file (under DOS/Windows).
   
The <TT>[[compile_to_c]]</TT> command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is <TT>make</TT>, which has to exist; otherwise, the creation method must be specified.
+
The <TT>[[compile_to_c]]</TT> command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is <TT>make</TT>, which has to exist; otherwise, the creation feature must be specified.
   
In all cases, the creation method must be one ''without arguments''.
+
In all cases, the creation feature must be one ''without arguments''.
   
 
=== Loading Eiffel files ===
 
=== Loading Eiffel files ===
Line 40: Line 40:
 
|-
 
|-
 
| valign="top" | <code>-version</code>
 
| valign="top" | <code>-version</code>
| Display the SmartEiffel version number.
+
| Display the Liberty Eiffel version number.
 
|}
 
|}
   
Line 47: Line 47:
 
==== Compilation mode ====
 
==== Compilation mode ====
   
There are eight compilation modes which give the eight levels of assertion checking. In ascending order of verification they are:
+
There are the following compilation modes which give different levels of assertion checking. In ascending order of verification they are:
* '''boost''' is a mode in which ''no'' validity checking is done and in which SmartEiffel does '''additional processing''' compared to the other modes. In particular, in this mode:
+
* '''boost''' is a mode in which ''no'' validity checking is done and in which Liberty Eiffel does '''additional processing''' compared to the other modes. In particular, in this mode:
** the execution stack is not managed by SmartEiffel,
+
** the execution stack is not managed by Liberty Eiffel,
 
** the behavior of certain language constructs is changed:
 
** the behavior of certain language constructs is changed:
 
*** no tests for Void (which leads to a segfault if there is any problem...)
 
*** no tests for Void (which leads to a segfault if there is any problem...)
Line 55: Line 55:
 
*** if <TT>else</TT> is missing from an <TT>inspect</TT> clause, the last branch is used for <TT>else</TT>,
 
*** if <TT>else</TT> is missing from an <TT>inspect</TT> clause, the last branch is used for <TT>else</TT>,
 
** <TT>and</TT> and <TT>or</TT> become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the <TT>and</TT> or <TT>or</TT> expression, like <TT>and&nbsp;than</TT> and <TT>or&nbsp;else</TT>)
 
** <TT>and</TT> and <TT>or</TT> become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the <TT>and</TT> or <TT>or</TT> expression, like <TT>and&nbsp;than</TT> and <TT>or&nbsp;else</TT>)
** SmartEiffel does an optimization pass; in particular, certain functions are put in line;
+
** Liberty Eiffel does an optimization pass; in particular, certain functions are inlined;
 
* '''no_check''' is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the <TT>Void</TT> tests and type checks are always done, and so on);
 
* '''no_check''' is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the <TT>Void</TT> tests and type checks are always done, and so on);
 
* '''require_check''' is a mode in which only the preconditions are checked;
 
* '''require_check''' is a mode in which only the preconditions are checked;
Line 62: Line 62:
 
* '''loop_check''' is a mode in which the preconditions, postconditions and class invariants are checked and loop variants and invariants are checked as well;
 
* '''loop_check''' is a mode in which the preconditions, postconditions and class invariants are checked and loop variants and invariants are checked as well;
 
* '''all_check''' is a mode in which all assertions (those above and the <TT>check</TT> clauses) are checked;
 
* '''all_check''' is a mode in which all assertions (those above and the <TT>check</TT> clauses) are checked;
  +
* '''debug_check''' is a mode in which all assertions are checked ''and'' the <TT>debug</TT> clauses are compiled too.
 
  +
The following minor modes may be combined with the compilation modes above:
  +
* '''flat_mode''' each assertion will be executed in no_check mode (non-recursive assertion checking), use in combination with any mode from require_check to all_check
  +
* '''debug_mode''' Compile debug blocks. This mode may be used in combination with any other compilation mode.
   
 
{| cellspacing="4" cellpadding="0" width="100%"
 
{| cellspacing="4" cellpadding="0" width="100%"
Line 88: Line 91:
 
|-
 
|-
 
| valign="top" | <code>-debug_check</code>
 
| valign="top" | <code>-debug_check</code>
| Activate '''debug_check''' mode. ''This level will disappear in 2.3. It is replaced by a -debug flag independent from the assertion level (see below).''
+
| Activate '''all_check''' and '''debug''' mode. ''This is deprecated as it is equivalent to '''-all_checkk&nbsp;-debug'''.
 
|-
 
|-
 
| valign="top" | <code>-debug</code>
 
| valign="top" | <code>-debug</code>
| ''New in 2.3:'' Compile debug blocks. This flag may be used with any other assertion level flag. The old <code>-debug_check</code> is deprecated and can be replaced by <code>-all_check&nbsp;-debug</code>.
+
| Compile debug blocks. This flag may be used with any other assertion level flag.
 
|}
 
|}
   
Line 100: Line 103:
 
{| cellspacing="4" cellpadding="0" width="100%"
 
{| cellspacing="4" cellpadding="0" width="100%"
 
|-
 
|-
| width="20%" valign="top" | <code>-no_style_warning</code>
+
| width="20%" valign="top" | <code>-style_warning</code>
| Suppress the display of warning messages about non-compliance with Eiffel style rules ''(this flag does not have any effect any more in 2.3)''.
+
| Display warning messages about non-compliance with Eiffel style rules.
 
|-
 
|-
 
| valign="top" | <code>-no_warning</code>
 
| valign="top" | <code>-no_warning</code>
| Suppress all warning messages. This implies <TT>-no_style_warning</TT>.
+
| Suppress all warning messages.
  +
|}
  +
  +
==== Message Styles ====
  +
  +
{| cellspacing="4" cellpadding="0" width="100%"
  +
|-
  +
| width="20%" valign="top" | <code>-flymake_mode</code>
  +
| Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.
 
|}
 
|}
   
Line 128: Line 139:
 
|-
 
|-
 
| valign="top" | <code>-relax</code>
 
| valign="top" | <code>-relax</code>
  +
| Perform fewer checks by considering less dead code, hence using less memory and less compilation time. Useful to prototype or to deliver safe code. (Useful too for very small computers.)
| '''?????''' <!-- Philippe or Dominique, please complete this -->
 
 
|}
 
|}
   
Line 149: Line 160:
 
| No [[garbage collector]].
 
| No [[garbage collector]].
   
When this option is used, the garbage collector is not produced and (at least) one <TT>malloc()</TT> is done for each object creation. This option is useful if you want to use another garbage collector from an external library, like the Boehm-Demers-Weiser one, for example, or when a garbage collector is not needed.
+
When this option is used, the garbage collector is not produced and (at least) one <TT>malloc()</TT> is done for each object creation. This option is useful if you want to use another garbage collector from an external library, or when a garbage collector is not needed.
   
Without this option, SmartEiffel builds a garbage collector tailored to the application.
+
Without this option, Liberty Eiffel builds a garbage collector tailored to the application or the BDW GC.
  +
|-
  +
| valign="top" | <code>-bdw_gc</code>
  +
| When this option is used, the Boehm-Demers-Weiser [[garbage collector]] is used instead of the traditional "SE GC".
 
|-
 
|-
 
| valign="top" | <code>-gc_info</code>
 
| valign="top" | <code>-gc_info</code>
| When this option is used, the [[garbage collector]] displays at run time some information about its use.
+
| When this option is used, the [[garbage collector]] displays information about its use at run time.
 
|-
 
|-
 
| valign="top" | <code>-cecil &lt;cecil_file&gt;</code>
 
| valign="top" | <code>-cecil &lt;cecil_file&gt;</code>
Line 160: Line 174:
 
|-
 
|-
 
| valign="top" | <code>-no_main</code>
 
| valign="top" | <code>-no_main</code>
| Do not generate a <TT>main()</TT> C function. In this case the root creation method is not called. This can be useful when you want to start execution from outside before calling Eiffel routines via the [[cecil]] interface.
+
| Do not generate a <TT>main()</TT> C function. In this case the root creation feature is not called. This can be useful when you want to start execution from outside before calling Eiffel routines via the [[cecil]] interface.
   
 
Before calling the first Eiffel routine, do not forget to call the routine <TT>initialize_eiffel_runtime(argc,&nbsp;argv);</TT> which initialises the Eiffel system.
 
Before calling the first Eiffel routine, do not forget to call the routine <TT>initialize_eiffel_runtime(argc,&nbsp;argv);</TT> which initialises the Eiffel system.
 
|-
 
|-
 
| valign="top" | <code>-sedb</code>
 
| valign="top" | <code>-sedb</code>
| This option allows you to include the [[sedb|SmartEiffel debugger]] in your executable.
+
| This option allows you to include the [[sedb|Liberty Eiffel debugger]] in your executable.
 
|-
 
|-
 
| valign="top" | <code>-profile</code>
 
| valign="top" | <code>-profile</code>

Latest revision as of 16:21, 7 July 2024


The compile_to_c command is the ANSI C code generator. This command is usually called automatically from compile, but you can also use it on its own to produce the C code. Like compile, there are two ways of running it: traditional mode and ACE mode.

  • In traditional mode, many options can be given on the command line.
  • In ACE (Assembly of Classes in Eiffel) mode, most of its options are not allowed on the command line; but they have equivalents in the ACE file.

Synopsis

  • se c2c [options] <root_class> [<root_procedure>]
  • se c2c [common_options] <ace_file.ace>

The first usage is traditional mode; the second is ACE mode.

In ACE mode, the name of the ACE file must end with the suffix .ace.

The compile_to_c command produces the C files (*.h and *.c). A script file is also created, whose name depends on the application. This is a .make file (under UNIX) or a .BAT file (under DOS/Windows).

The compile_to_c command must have at least one argument which specifies the program's starting point; this is in fact a class's creation procedure. In ACE mode this data is obtained from parameters in the ACE file. In traditional mode, at least the class name must be specified; the default name of the creation class is make, which has to exist; otherwise, the creation feature must be specified.

In all cases, the creation feature must be one without arguments.

Loading Eiffel files

The compile_to_c command uses the same process as finder to find and load the Eiffel files to compile. Note that, as with finder, the process differs according to whether you are using traditional or ACE mode.

Common options

These options can be used both in ACE mode and in traditional mode.

-help Display a short summary of the command line syntax, with a complete list of the compiler options.
-verbose Display (an enormous amount of) information during compilation: a complete trace of files loaded, type inference scores, generated files and so on.
-version Display the Liberty Eiffel version number.

Options specific to traditional mode

Compilation mode

There are the following compilation modes which give different levels of assertion checking. In ascending order of verification they are:

  • boost is a mode in which no validity checking is done and in which Liberty Eiffel does additional processing compared to the other modes. In particular, in this mode:
    • the execution stack is not managed by Liberty Eiffel,
    • the behavior of certain language constructs is changed:
      • no tests for Void (which leads to a segfault if there is any problem...)
      • no tests for type conformity (ditto; cf the forced assignment operator ::=)
      • if else is missing from an inspect clause, the last branch is used for else,
    • and and or become semi-strict (i.e. the second expression may not be evaluated if the first expression is enough to infer the result of the and or or expression, like and than and or else)
    • Liberty Eiffel does an optimization pass; in particular, certain functions are inlined;
  • no_check is a mode in which no validity checking is done, but the above optimizations are not done (in particular, the execution stack is always managed, the Void tests and type checks are always done, and so on);
  • require_check is a mode in which only the preconditions are checked;
  • ensure_check is a mode in which the preconditions and postconditions are checked;
  • invariant_check is a mode in which the preconditions, postconditions and class invariants are checked;
  • loop_check is a mode in which the preconditions, postconditions and class invariants are checked and loop variants and invariants are checked as well;
  • all_check is a mode in which all assertions (those above and the check clauses) are checked;

The following minor modes may be combined with the compilation modes above:

  • flat_mode each assertion will be executed in no_check mode (non-recursive assertion checking), use in combination with any mode from require_check to all_check
  • debug_mode Compile debug blocks. This mode may be used in combination with any other compilation mode.
-boost Activate boost mode.
-no_check Activate no_check mode.
-require_check Activate require_check mode.
-ensure_check Activate ensure_check mode.
-invariant_check Activate invariant_check mode.
-loop_check Activate loop_check mode.
-all_check Activate all_check mode.
-debug_check Activate all_check and debug mode. This is deprecated as it is equivalent to -all_checkk -debug.
-debug Compile debug blocks. This flag may be used with any other assertion level flag.

Warnings

These options affect the compilation process, but do not change the generated C code.

-style_warning Display warning messages about non-compliance with Eiffel style rules.
-no_warning Suppress all warning messages.

Message Styles

-flymake_mode Display messages in a compact format suitable for processing by tools such as Emacs' Flymake mode.

Advanced options

Not affecting the generated C code

These options affect the compilation process, but do not change the generated C code.

-o <executable> Specify the name of the executable program.
-loadpath <loadpath_file> Add a file containing Eiffel class search paths. For details see the finder command.
-no_strip Do not strip symbol data from the executable file. This option is useful for debugging the C code (either generated or included code).
-high_memory_compiler Allow the compiler to use more memory... This can allow faster compilation, if you have enough RAM.
-relax Perform fewer checks by considering less dead code, hence using less memory and less compilation time. Useful to prototype or to deliver safe code. (Useful too for very small computers.)
Affecting the generated C code

These options change the generated C code.

-c_mode <C_mode> Use a different C mode.
-cc <C_compiler> Call the specified C compiler instead of the one in the default configuration. This option is incompatible with <-c_mode> and should generally be avoided except under very special circumstances.
-no_split Produce a single C file containing the entire application. This can allow the C compiler to do a lot of optimisation and is therefore useful for the production stage of a project. This option is usually implied if you use -c_mode release.
-no_gc No garbage collector.

When this option is used, the garbage collector is not produced and (at least) one malloc() is done for each object creation. This option is useful if you want to use another garbage collector from an external library, or when a garbage collector is not needed.

Without this option, Liberty Eiffel builds a garbage collector tailored to the application or the BDW GC.

-bdw_gc When this option is used, the Boehm-Demers-Weiser garbage collector is used instead of the traditional "SE GC".
-gc_info When this option is used, the garbage collector displays information about its use at run time.
-cecil <cecil_file> Allow Eiffel features to be called from C (see cecil for details).
-no_main Do not generate a main() C function. In this case the root creation feature is not called. This can be useful when you want to start execution from outside before calling Eiffel routines via the cecil interface.

Before calling the first Eiffel routine, do not forget to call the routine initialize_eiffel_runtime(argc, argv); which initialises the Eiffel system.

-sedb This option allows you to include the Liberty Eiffel debugger in your executable.
-profile This option allows you to include the profiler in your executable.
-manifest_string_trace This option allows you to include in your executable a trace of the creation of manifest strings. This can be useful for tracking down some memory errors.

Options passed to the C compiler

All unrecognised options are passed to the C compiler.

Generation

(to be completed...). See C code generation