How to Use the Vortex Compiler

1 Introduction

The Vortex compiler's whole-program analyses introduce complex intermodule dependencies, rendering the standard header file and make-based approach to incremental compilation untenable. Instead, Vortex tracks intermodule dependencies in a program database, enabling it to determine which compiled files must be recompiled after a programming change. The current Vortex compiler keeps this database in memory while running and supports operations to dump the program database to disk and later read the program database back from disk. The file containing the program's database and other information about the state of the compiler is called the program's checkpoint.

Given whole-program analysis and optimization, each program's compiled code (including libraries) is tuned to that particular application and consequently it cannot be shared with other applications (with the exception of sharable, separately-compiled libraries; see section 5). In general, each application must be compiled into its own directory. We call this directory the application's gen directory (short for "generated code"). Vortex places all generated files (except for files that are part of separately compiled libraries) including the final executable and the program's checkpoint in the gen directory.

Vortex compilation occurs in three phases. In Phase Zero, a Vortex front end translates non-Cecil programs into the Vortex RTL intermediate language. In Phase One, Vortex translates a RTL or Cecil source program into either C++ or assembly code. In Phase Two, a C++ compiler or an assembler translates the output of Vortex into object files and an executable. Currently the only architecture/operating system combination supporting assembly codegen is SPARC/SunOS 4.

How to Use the Vortex Compiler - 20 JAN 97

[Next] [Previous] [Top]