OC(1)

NAME
oc, oc1, oc2 - Opal compiler

SYNOPSIS
oc{1,2} [ -s | -i | -E | -I ] [ -v[ level] ] [ -w[ level] ]
[ -o[ kind] ] [ -d[ kind] ] [ -tn ] [ -zoption ] ...
[ -hdir | -edir ] [ -r | -b ] structure ...

DESCRIPTION

The Opal compiler oc is made up of a frontend oc1(1) and a backend oc2(1) that produces C code. The C Code must be further translated by a C compiler. It is not intended to execute oc1 or oc2 directly, but to use the Opal compilation system driver ocs(1) or the Opal release system driver ors(1). The former is based on GNU make(1) while the latter requires Shape Tools shape(1).

oc1 translates a signature part of an Opal structure to a signature export file, or an implementation part of an Opal structure to intermediate applicative code. oc2 optimizes the applicative code and translates it into a C file.

Both oc1 and oc2 accept the same command line options, though some options are ignored by one end of the Opal compiler. All structures involved in a compilation must be given on the command line. The source structure is the first structure; all imported structures must follow.

Unless a -hdir or -edir (directory) option precedes a structure, the structure's files are located in the current working directory, which is assumed to be a hidden Opal directory. In a hidden Opal directory, compilation products (export files, object code, as well as diagnostic files) are located in a special subdirectory named OCS, whereas in an expanded (or visible) Opal directory, all compilation products are located in the directory itself.

OPTIONS

-s  Compile SIGNATURE part of the source structure.

-i  Compile IMPLEMENTATION part of the source structure. This is the default.

-E  Compile EXTERNAL PROPERTIES part of the source structure. This is only legal if the Opal property language is activated with the -zprop option (see below).

-I  Compile INTERNAL PROPERTIES part of the source structure. This is only legal with the -zprop option set (see below).

-hdir
    The derived files of the following structures are located in the directory dir/OCS. This option can be repeated.

-edir
    The derived files of the following structures are located in the directory dir. This option can be repeated.

-r  The following structures are taken to be released, i.e., the implementation parts and their compilation products may be used for optimization purposes in the translation of the source structure. This option can be repeated.

-b  The following structures are taken to be busy, i.e., the implementation parts and their compilation products may not be used. This is the default. This option can be repeated.

-v[level]
    Verbose compilation. The default is -v0; -v with the level omitted is equivalent to -v1. level is one of:

    0   Quiet compilation.

    1   Display the compilation phases.

    2   Display the compilation phases and their subphases.

    3   Display even minor compilation steps.

-w[level]
    Display warnings. The default is -w1; -w with the level omitted is equivalent to -w2. level is one of:

    0   Do not generate warnings. Only errors are displayed.

    1   Display warnings, e.g., a duplicate pattern.

    2   Like -w1, but additionally display hints, e.g., missing patterns.

-o[kind]
    Controls code optimization. The default is no optimization; -o with the kind omitted is equivalent to -o1. kind is a combination of:

    1   This is an alias for the combination esucm.

    2   This is an alias for the combination 1pgT.

    e   Perform common subexpression elimination.

    s   Perform simplification of expressions by exploiting the axiomatic semantics of the functional core.

    u   Perform unfolding of function definitions and of local equations. This option allows the Opal compiler to code functions and equations in a non-strict fashion. The resulting program is only robustly correct, i.e. satisfies the semantics only for terminating programs.

    c   Perform optimization of constant expressions. The resulting program evaluates each detectable constant expression not more then once. Note that the memory allocated by the object resulting from this evaluation can never be retrieved.

    m   Perform optimization of memory allocation and garbage collection. The resulting program realizes direct reusage of memory cells and selective update of single-threaded data objects.

    p   This option allows the Opal compiler to treat runtime errors of partial functions as a "no-case", which allows some subtle optimizations. It results only in robustly correct code.

    g   This option enables the use and generation of the optimization export files for global inter-structure optimizations (if they are released, see the -r option). Function definitions and properties are made available across structures boundaries. The use of this option enforces recompilation dependencies between structure implementations.

    T   This option generally allows the Opal compiler to perform some optimizations which might be expensive with respect to compilation time.

    S   This option generally allows the Opal compiler to perform optimizations which might be speculative by with respect to the code size (but not to the code speed).

-d[kind]
    Controls generation of code for debugging. The default is to generate no code for debugging; -d with the kind omitted is equivalent to -dd. kind is a combination of:

    d   Generate information for use in an object code debugger.

    T   Generate code for tracing all function entries and exits. Depending on the optimization level, not all function calls are considered.

    t   Generate code for tracing all entries and exits of exported functions. Depending on the optimization level, auxiliary functions may be implicitely exported.

-tn Locate intermediate files and the generated C file in /tmp. n has to be a unique number to distinguish intermediate files from different compilation processes, usually a process number. If this option is used, intermediate files are removed; otherwise they are preserved for recompilation purposes.

-zoption
    option is taken as special compiler option; it can be an arbitrary text. This option can be repeated. Several z options have recently been added to support language extensions. The current release enforces the setting of the following set of z options to support the official Opal implementation language.

    etaEnrichment
        Enriches function definitions with missing (curried) arguments, i.e. DEF f == succ is treated as DEF f(N) == succ(N).

    underline
        Allows alphanumerical and graphical Opal names to be combined into a single name using an underline character, i.e. aa_.. or aa_bb.

    wildcard
        On left-hand sides one or more unused variables can be denoted by a single underline, i.e LET (a,_,_) == ... . Note, however, that a single underline is no longer a valid Opal name.

    section
        In an expression on the right-hand side a single underline in place of an argument causes the expression to be (lambda) abstracted over that argument, i.e. (_ +b) stands for (\\N.N +b).

    seqGuards
        Within IF conditions the newly introduced keywords ANDIF and ORIF are boolean operators which will sequentially evaluate their arguments.

    infix
        This supports a sequence of unbracketed expressions (multiple infix), if and only if the types of all expressions determine a unique bracketing, i.e. a::b::c::d::S becomes a::(b::(c::(d::S))).

    rassoc
        In conjunction with -zinfix a sequence of expressions with the same infix operator is taken to be right associative, i.e. 1+2+3+4 is 1+(2+(3+4)). Note that this is not always what you want, because (3-(2-1)) is not ((3-2)-1). Note also that 1-2+3, for example, will not be resolved, because - and + are different operators.

    The following z options may be useful in experimental settings.

    interOpal
        Generates an intermediate representation of the analyzed Opal structure for use of other Opal development tools.

    prop
        This switches on the Opal property language, which allows one to write down algebraic properties of Opal objects.

    onlyParse
        Parses only the source structure and generates the abstract syntax.

    doNotParse
        Compiles the source structure, but reads the previously generated abstract syntax.

    The following z options support the hand-coding of Opal structures in C.

    gForeignInterface
        Generate a C header file of the compiled structure which declares symbolic names for the implemented functions.

    gForeignTemplate
        Generate files structure.h.tmpl and structure.c.tmpl where the header file declares symbolic names as with -zgForeignInterface, while the C file contains a template which can be used for further C handcoding.

    There are many other z options which allow special compiler outputs and/or different compilation alternatives. These are further documented in Special Options of the Opal Compiler.

FILES
structure.sign
    signature part of structure
structure.impl
    implementation part of structure
structure.extp
    external properties part of structure
structure.intp
    internal properties part of structure
structure.x.diag
    diagnostic file containing all errors, warnings and hints generated during the compilation of structure, where x stands for one of sign, impl, extp or intp.
structure.deps
    dependency file for the compilation products of structure. It contains recompilation information and a list of files used during compilation.
structure.absy
    contains the abstract syntax created with the z option onlyParse of structure.
structure.exp
    signature export file for structure
structure.impl.exp
    implementation export file of structure to be used within internal properties
structure.extp.exp
    external properties export file of structure to be used by other property parts
structure.ana
    intermediate file for analyzed implementation part of structure containing the applicative code.
structure.opt
    implementation export file of structure to be used for global optimization
structure.h
    include file for structure
structure.c
    C file for structure

SEE ALSO
ocs(1),

A User's Guide to the Opal Compilation System.

P. Pepper (ed.), The Programming Language Opal, Technical University of Berlin, FB 13.

The Opal1-Tutorial

The Opal Standard Library.

Handcoder's Guide to the Opal Compilation System Version 2

DIAGNOSTICS
oc returns an exit status of 0 if the compilation has been successful; it returns an exit status of 1 if errors were found in the compiled structure part; if command line options are wrong or errors occur during file i/o, it returns an exit status of 2; if compiler restrictions were disregarded it returns an exit status of 255.

The diagnostics produced by the Opal compiler are intended to be self-explanatory.

BUGS
The compiler contains other bugs which are described in Report on Bugs, Missing Features and Other Deficiencies of the Opal Compiler. Please refer to the User's Guide to the Opal Compilation System for how to identify a bug. We encourage you to send bug reports to opal-bugs@cs.tu-berlin.de via ocs sendbug.

NO WARRANTY
The OPAL Compiler is an experimental research product and is licensed free of charge. Therefore, we provide ABSOLUTELY NO WARRANTY of any kind in any case. The Technical University of Berlin and the authors provide this software package "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchandizing and fitness for a particular purpose. The entire risk as to the quality and the performance of the program lies with you.

In no event may the Technical University of Berlin or any of the program's authors be liable to you for damages, including any lost profits, lost monies, or other special, incidental, or consequential damages arising out of the use of or inability to use the program, even if you have been advised of the possibility of such damages, or for any claim by any other party.

AUTHORS
The language OPAL was designed by Gottfried Egger, Andreas Fett, Carola Gerke, Wolfgang Grieskamp, Michael Jatzeck, Peter Pepper, and Wolfram Schulte. The frontend of the OPAL compiler was designed and implemented by Andreas Fett, Michael Jatzeck, and Carola Gerke. The backend was designed and implemented by Wolfram Schulte and Wolfgang Grieskamp.

The OPAL Group may be contacted at: Technische Universitaet Berlin, Institut fuer Angewandte Informatik, Sekretariat FR 5-13, Franklinstr. 28/29, 10587 Berlin, email: opal@cs.tu-berlin.de or opal-discussion@cs.tu-berlin.de