lus2oc, ec2oc - lustre to Lustre/Esterel Object Code
lus2oc file.lus node [options]
ec2oc file.ec [options]
The lus2oc command requires a file and a main node; it first calls lus2ec to build the corresponding expanded code, then calls ec2oc with all remaining options.
The ec2oc command builds a sequential program structured as an automaton. Several options allow the user to adjust the automaton generation. The default target format is oc version 5, but the version 2 is still supported, for compatibility with old tools. The default is to write the result in the file "node.oc".
set the verbose mode.
print available options.
print default options.
define the output file.
implement Boolean inputs/outputs with "pure" signal (i.e. side-effects). The default is to implement Boolean inputs/outputs with "classic" variables, just like integer or reals.
implement the lustre type real with the target type double (the default target type is float).
(default) the initial operator network is minimized before code generation. This minimization is a kind of "common sub-expression checking" except that the network may contain cycles; as a consequence this phase can be expensive, so the user can disable it (cf. -nomin).
disable the minimization of the operator network (cf. -min).
perform static computation of constant expressions.
generate an oc V2 file.
(default) generate an oc V5 file.
The main control structure is an automaton, obtained by static simulation of the Boolean variables (called state variables). The user can select the set of state variables:
no state variable; the resulting automaton has only one state. This mode is not supported if the source program contains clocks.
only clocks are simulated. For single-clocked program, the resulting automaton has always 2 states (the initial one and the non-initial one).
(default) all Boolean variables are simulated; the resulting program is the "fastest" code that can be generated, but unfortunately its size may be exponentially greater that the source code one. It it advisable to use the -v option, in order to stop the compilation if the automaton size grows too much.
The user may choose between two algorithms for the generation:
(default) the data-driven algorithm simulates the Boolean variables without taking into account their actual influence on the outputs. The resulting automaton is in general non-minimal according to the output computation.
works in data-driven mode. The generation stops after the specified number of states (default 10000). This limit avoids the generation of too huge code.
the demand-driven algorithm builds a automaton just "big" enough to perform the computation of the outputs. Using this option is quite equivalent to perform a standard minimization on the automaton produced by the data-driven algorithm.
The user can select the way conditional statements are treated:
forbid code duplication, i.e. tests are closed as soon as possible.
(default) use an heuristic for opening/closing tests; it forbids duplication of "big" parts of code.
forbid test duplication, i.e. tests are closed only when they are no longer needed.
forbid test closing; this option is the worst one in term of code size, but it can be very useful for analysing the program (see in particular lus2atg).
The bdd (binary decision diagrams) library is one of the most critical (time and space cost) part of the compiler. The user may change some parameters in order to improve compilation time.
perform a "clever" variable ordering before building bdds; this option is sometimes useful when the state generation step cannot even start.
the space devoted to bdds is allocated by pages. Before allocating new pages, the program first performs garbage collection; for big programs, frequent garbage collection may dramatically slow down the compilation, so the user may increase the size of pages, expressed in kilo-unit (default 10).