[Next] [Previous] [Up] [Top]
2 Building Your Program
Vortex's behavior is controlled by configuration parameters and options; the primary distinction between them is that options are set and queried by a regular set of commands, while manipulation of configuration parameters is currently more ad hoc. This section describes configuration parameters and a few important options. Section 2.4 describes options and how to set or display them in more detail.
Vortex displays its configuration upon startup; you can also request it with the config command. The configuration is part of the compiler state saved in a checkpoint.
Current program. At each moment, Vortex works with a single program. If the program consists of one file, this file is the current program. If the program consists of multiple files, the current program is the file from which the others are included, possibly indirectly. The current program is set by any of the make commands, for example,
- make progame.ext -- set current program to progname.ext and compile it
No current program is assumed upon Vortex startup.
Vortex can compile multiple languages. Cecil is the most stable input language, but C++, Modula-3, and Java bytecode front-ends are also available. To set the language being compiled, use the lang command:
- lang (Cecil|C++|Java|M3) -- change the current accepted language (Cecil by default)
The compiler prompt reflects the current source language setting (although we use Cecil> throughout this document for simplicity). Regardless of the current language, the set of compiler commands and options remains the same, and only Cecil expressions are recognized by the evaluator (since they are evaluated in the context of the Vortex compiler's implementation, which is written in Cecil). Filename extensions have no influence on the current language, nor is any specific extension enforced.
Generated language. Vortex generates either C++ or assembly code.
- gen (C|asm) -- generate C++ or assembly code (C++ by default)
- gen (Sparc|...) -- select the target architecture (Sparc by default, and only Sparc allowed at present)
Cecil standard library. The Cecil language includes no built-in data or control structures. When compiling a Cecil program, Vortex can automatically include the standard library, a selection of standard data and control structures (e.g. numbers, loops, arrays) plus the Cecil evaluator, which facilitates debugging the program. Alternately, you may select a subset of the standard library, or no library at all.
(When compiling a language other than Cecil, no standard library may be included.)
There are four levels of incorporating the Cecil standard library (described in more detail in a separate document), depending on the top library file that is included in the program (including a file causes other files referenced in it to be included, too). The levels are determined by compiler commands as follows:
- nostdlib -- no files are automatically included by Vortex, so no data and control structures are implicitly available.
- smallstdlib -- prelude.small.cecil is automatically included. It provides only the core standard data structures (see standard library reference for details). Note: the smallstdlib is incomplete (in particular it excludes big_ints and streams), thus a number of warning messages (which can be ignored) will be generated when compiling the smallstdlib's files.
- noevalstdlib -- prelude.noeval.cecil is included. It provides all the standard data structures, but excludes the Cecil evaluator.
- stdlib (default) -- prelude.cecil is included, providing the Cecil evaluator in addition to the standard data structures
These commands are processed in addition to any files included by the Cecil program. Choosing nostdlib and explicitly including prelude.cecil from one of the files comprising a program is equivalent to choosing stdlib when compiling that program (even if it contains no explicit includes).
Optimization level. When debugging code, it is convenient to compile it without optimizations both to reduce turnaround time and to make it easier to use the Cecil evaluator and debugger (discussed in sections 3 and 4). We typically make some source changes, do a series of incremental, non-optimizing compilations while debugging, and finally perform an optimizing compilation once things seem to work. Optimization speeds up applications by roughly an order of magnitude, so it generally is a good idea to optimize a program before running it on a large input set.
Which optimizations are performed depends on the value of the integer option optimization_level; larger values of optimization_level correspond to more aggressive combinations of optimizations. Its default value is 0 (perform no optimizations). It may be set using the following commands:
Since separately-compiled libraries (such as the precompiled standard library that comes with the distribution) are compiled with no optimization, you need to disable separate compilation (i.e., enable whole-program optimization) to achieve higher performance. This is controlled by the option specialize_libraries.
- set specialize_libraries (true|false) -- make/do not make a specialized version of all library code in the application's gen directory (default value is false)
Be prepared for a long compilation time when you first set specialize_libraries to true, since all the library files will need to be recompiled. You may want to switch to a smaller standard library before specializing library code.
In a large program, often only a few files are being debugged at a time. In such a case, it is reasonable to optimize the other files. This is achieved by first compiling everything with optimization ( Cecil> set specialize_libraries true; o2; make) and then turning optimization off ( Cecil> o0). After these actions, every file that is modified will be recompiled without optimization (thus making debugging easier and reducing turnaround time). The command Cecil> makeo2 will then recompile unoptimized files with optimization, bringing the current program up to full optimization. makeo1 and makeo2 set the optimization_level option for only the immediately succeeding compile. It is reasonable to keep optimization_level set to 0, but periodically use makeo1 or makeo2 to bring things up to full speed.
How to Use the Vortex Compiler - 20 JAN 97
[Next] [Previous] [Up] [Top]