GRL compiler interface
The GRL compiler is divided into a set of Scheme packages: girl-compiler,
girl-top-level, and the various auxilliary back
ends. The compiler works by compiling code into an intermediate language,
which is a subset of Scheme. Intermediate language code is non-recursive and doesn't
perform any run-time type checking or storage allocation. That is to say, it might
as well be C.
Compilation procedures are called with a list of roots. Roots can be
signals, lists of signals, lists of lists of signals, etc. They're called roots
because the compiler performs a depth-first search of the graph of all signals, starting
from the roots. Any signal that is encountered in the process of the walk is emitted
as intermediate code. Other signals are ignored.
The girl-top-level package provides access to a set of procedures that allow you
compile intermediate code from a list of roots. Since they generate intermediate
code, they are mostly useful for examining the code being generated by the compiler.
When compiling code for real, you will most likely use a back end tailored for your
specific robot or target language.
- (compile roots ...)
- Compiles roots to Scheme intermediate code and displays it on the screen or in
the output file specified by the :output-file compiler
- (compile-to-file file-name roots ...)
- Compiles roots to Scheme intermediate code and writes it to output-file.
- (compile-and-run roots ...)
- Compiles roots to Scheme intermediate code and evals the code. This lets
you do limited testing on your desktop, or to run the girl compiler directly on
your robot if it supports Scheme48.
The back ends
There are a number of back ends available for the compiler. To use one, open its
package or another package that exports it (see the release
notes) and call the appropriate procedure. Each back exports a pair of
procedures, compile-to-X and compile-to-X-file,
which have the same arguments as compile and compile-to-file, but happen to generate code for X.
This package is mostly intended for programmers developing new back ends.
However, some of the options will also be useful for powerusers trying to tweak the code
generated by the compiler. The only procedure exported by the package that should be
called by normal users is compiler-options. It
takes a list of keywords and values, a la Common Lisp.
User-level compiler options
- Specifies target frequency of main command loop.
- Prevents inlining of some or all signals. If #t, then no signals are inlined.
If 'roots, then only the signals specfied in the call the compiler will be
prevented from being inlined.
- The name of the procedure that will contain the main while loop.
- A string to be prepended to every temporary variable generated by the compiler.
Used to prevent name collisions when two different programs generated by the compiler are
to be run in parallel.
Mostly used for compiler debugging
- Compiler pretty-prints Scheme intermediate code before partial evaluation.
- Compiler pretty-prints Scheme intermediate code after partial evaluation.
- Compiles displays list of all signals encountered during its inital walk of the signal
- Compiles displays final sorted list of all primitive signals for which code is to be
Internal compiler options
- The procedure called to print the intermediate code
- The file to write the code to. #f means write it to the screen.
- Whether to add type information to variable declarations in the intermediate code
- Forces all variables to be global
- Whether extra debugging information should be added to the object code
- Whether the code should be wrapped in a while loop
- Prevents if and nth calls from ever being inlined
- If false, lets will be changed into applications of lambdas.
- Prevents if from being placed in an subexpressions.
- Whether these should be translated into ifs.
- Whether the compiler should tell you about cycles in the signal graph