The word ``Compiler'' in the name of this section refers to the LISP C compiler. This compiler is actually a LISP program. It constitutes of two functional parts. One is the part that is proposed as A Portable LISP Compiler, by M. L. Griss and A.C. Hearn. This part generates a compiled code in terms of some macros that correspond to certain actions of the underlying LISP system (e.g. calling a compiled function, pushing some LISP object on stack, accessing the stack, etc.) It is actually portable, because what is needed is only a secondary process, done again in LISP, that will take this macro involving code and looking at it produce a code in the target language (in our case C). One has to point out that the A Portable LISP Compiler assumes an underlying register implementation. This is another aspect which biased our decision towards a register implementation rather than a stack one. We name the second part, that converts the macros to the C code, as lap In our implementation lap performs some code refinements too. The lisp source of lap lives in the file lap.lsp distributed. So, a full bootstrapping of the compiler including LISP is nothing else then performing a LISP code compilation. But how to get the first working compiler? It is trivial that this ...Egg Chicken...Egg Chi cken ...chain has to start somewhere. One answer is: You get a LISP interpreter compiled (the previous section) you load the LISP code for the compiler, namely the file compiler.lsp you load the LISP code for the lap, namely the file lap.lsp and you get an interactive working compiler, you supply this interactive compiler the same LISP sources of the compiler+lap, by a compilefile LISP function call (see below for the arguments) and then you wait for ages to get the first ``Chicken'' out. We did this process. For your benefit we have not thrown away the C code that came out to produce this ``Chicken''. In the source supplied, you will find a set of files collected under a subdirectory named compiler The files included in this set are the outcome code of the compilation of the compiler (those having names that start with the letters comp and have no file extensions. In order to get a working version of LISP, having the compiled compiler present, follow the steps:
We do have to recreate lisp1.c because this file will contain some static data which will be created looking at some of the files of the compiler \ package
If you have not missed anything, now you must have to hand the object codes for lisp1 lisp2 and those objects which are the result of the compilation of the crc \ produced C sources.
UNIX users: You can do all the compilation and linking of lisp1.c lisp2.c and the lispc#.c files just in one line, namely:
cc lisp*.c -lm-lm links in the standard math library
If you omit this the default name LISP-INI \
will be given.
If you decide to use the second command line argument don't
forget to submit the first one which is: comp for
the compiler compilation,
and some other generic name you once gave (see the section
``Compiling a LISP Code'') otherwise
At run time, an environment variable should be set to the
name of the initialization
file (including the full path), and furthermore
the LISP that you are created shall be informed
at run-time about this
enviroment variable by a command line option -E (for
details see relevant explanation in this manual).
If you do not use the
-E option then the LISP you compiled will look for
an environment variable with the name LISPINI If you forget to set the environment variable
to point to the initialization file, and the initializiation
file is not in the current directory then
the LISP that you have created, will
abort, at run-time, with an error indicating that the
initialization file is absent