4.2BSD/usr/lisp/franz.n
." franz.n -[Thu Jun 17 11:01:27 1982 by jkf]-
." this file will contain a description of the franz lisp system.
." sort of a systems manual.
.de Fr
F\s-2RANZ\s0 L\s-2ISP\s0
..
.tp
.(l C
.sz +2
\fBThe Franz Lisp System\fP
.sz -2
.sp 2v
\fIby
\fIJohn K. Foderaro\fP
.)l
.sp 3v
.tl ''Abstract''
.br
This document describes the
.Fr
system written at The University of California
at Berkeley.
Included are descriptions of the memory management, interpreter
and compiler, the conventions used within the C coded kernel
and those within the compiled code.
This does not duplicate the information found in The Franz Lisp Manual.
.++ C '\s-2Draft\s+2'\fBThe\ Franz\ Lisp\ System\fP'%'
.+c Characteristics\ of\ \F\s-2RANZ\ \s0L\s-2ISP\s0
.ls 1
.pp
There is no formal standard for lisp systems, thus each lisp
system is almost guaranteed to be different from any other lisp system.
In this section we will examine the design decisions which most often
characterize a lisp system.
This
focus does not imply that all other parts of the language are generally
agreed upon.
In fact, there is nothing sacred to lisp system designers.
For example, one usually identifies the symbol
.i nil
with the empty list,
and one usually thinks of lisp as a dynamically scoped language.
Both of these conventions are are not true in the lisp dialect
.i NIL
currently being written at MIT.
As another example, one imagines that a lisp system must
use garbage collection to reclaim storage.
The lisp dialect
.i ZetaLisp
that is running on Lisp Machines doesn't
normally use a garbage collector
because of the way in which it allocates its address space.
It is faster to reboot the machine than to do a garbage collection.
In most lisp dialects the lisp expressions are written in
parenthesised form. In
.i Portable
.i Standard
.i Lisp
(PSL) at the University of Utah, programs are written
primarily
in an Algol-like
syntax.
.pp
Thus some of the discussion to follow indicates not so much
.i unique
charateristics of
.Fr
but instead, how decisions were made.
.sh 2 Scoping\ and\ Binding
.pp
The
.Fr
interpreter
uses
.i dynamic
.i scoping ,
that is, after A calls B, B can access all of the
variables that A allocated
as well
as those that A can access, provided B doesn't allocate variables of the same
names.
There are two popular ways of implementing dynamic scoping:
.i deep
.i binding
and
.i shallow
.i binding .
Note that we will use the terms variable allocation and lambda
binding interchangeably in this report.
The former term is less language-specific than the latter.
.sh +1 Deep\ Binding
.pp
In a deep binding implementation, when a variable is allocated,
the name of the variable and a space for its value are pushed on the
top of a stack.
When a program asks for the value of a variable,
the lisp system must search down the stack for the first occurrence of
the variable.
This system offers great flexibility for the
programmer since the state of his program
can be described by the contents of the stack.
It is thus possible to save the context of a program by just saving
the stack or in some cases just a pointer to
a place in the stack.
The problem with deep binding is that it is time-consuming to search
down the stack for the value of a variable, and,
as a result, most systems
modify the deep binding model by giving variables a global value
cell and allowing programs to set and access the global cell.
Some implementations of Interlisp use deep binding.
.sh +0 Shallow\ Binding
.pp
In a shallow binding implementation, each variable has a global value cell
which contains the current value of the variable.
When a variable is allocated inside a program, its name
and old value are pushed on a stack called a
.i bindstack .
The variable is then given a new value.
Throughout the lifetime of the allocation, the current value of the
variable can be found in the global value cell associated with the variable.
When leaving the context of the variable's allocation, the old value
is restored from the
.i bindstack .
A shallow binding scheme makes it much cheaper to access
the values of variables, however it is much more difficult to
save the state and to restore it.
.pp
.Fr
and most other lisps which are not derived from Interlisp
use shallow binding.
Some versions of Interlisp use shallow binding.
.sh -1 Lisp\ Compiler
.pp
Dynamic scoping often is not necessary and it is never cheap, even
in a shallow binding implementation.
Thus the
.Fr
compiler prefers to do lexical scoping rather than dynamic
scoping.
If the user does not specify otherwise, when a
function is compiled, all variables
allocated will be
put on a local stack and will
.i not
be accessible by any
function that this function calls.
This
convention results in faster code being generated by
the compiler, but if the
user is not careful, it can result in compiled and interpreted code
working differently.
In some of the new lisp designs, such as
.i NIL
and
.i Common
.i Lisp
the semantics of compiled and interpreted code have been
unified by
transferring the compiler semantics (lexical scoping) to the interpreter.
This is a rather large step
if dynamic scoping is no
longer an option, and it is not clear whether the resulting
language should be called 'lisp'.
.sh +0 Data\ Types
.pp
A complete list of data types in
.Fr
can be found in the first chapter of the
.Fr
Manual.
The most important ones are described below.
.pp
Lisp is a list processing language and the basic data type is the list
cell.
A list cell also goes by the name of cons cell, pair, or dotted pair (dtpr).
It contains pointers to two lisp objects, and these pointers can
be accessed via the
.i car
and
.i cdr
functions.
Each pointer requires four (8-bit) bytes and thus the list cell is
eight bytes large.
The cdr pointer is stored first since this makes it easier
to 'cdr down a list' using the addressing modes of the VAX.
.pp
The symbol cell is used to implement variables. It contains a pointer
to a string that is the print name, a cell to store a value, a cell to
store the function definition, a cell to store a pointer to the property
list and one pointer that the list system uses if it stores
the symbol in the oblist.
.sh +0 Memory\ Management
.pp
A lisp system must be able to determine the type of an
object at run time.
The method used to determine the type influences the
way storage is managed and garbage collection is done.
Next, we will look at three possible places
to store the type information.
.sh +1 Typed\ data
.pp
The type of the data object could be placed in the object itself, much
as Pascal stores the type of a variant record in the record itself.
This could result is a large amount of storage being used to store
type information.
No lisp system that we know of uses this method exclusively.
.sh +0 Typed\ pointers
.pp
Every reference to a lisp object could contain the type of the object
referenced.
This is a good idea in a machine like an IBM 370 where only
part of machine word is used by the addressing hardware.
Lisps that use typed pointers generally use a
.i heap
memory management scheme and a
.i copying
garbage collector.
In a heap scheme,
all memory is divided by a pointer (called the
heap pointer) separating lisp
data and free space.
When a new lisp object is needed, it is formed at the
dividing line and then
the heap pointer is incremented
past the new object.
Garbage collection is done by maintaining two separate spaces for lisp
data, only one of which is used at any one time.
When one fills up, all active lisp objects are copied to the
other space, leaving the first space totally free.
Subsequent allocations are done from the second space, until it fills up,
at which point
all active data in the second space is copied to the first space.
The advantage of the copying garbage collector is that the data space
is compacted, which will improve virtual memory behavior.
The disadvantage is that
half the data space is always unused.
.pp
PSL on a PDP-10 uses this scheme, as does Lisp 370 on
an IBM 370.
PSL and NIL on the VAX will also use this scheme.
Since the VAX hardware
uses the entire word for address
calculation,
PSL and NIL
must mask off the type bits
of a pointer before using it to reference memory.
.sh +0 Typed\ pages
.pp
The final alternative is to allocate data objects by pages rather than
individually.
Each page contains only one type of object and there is a table that
keeps track of the type of data object in each page.
The address of an object tells which page the object is on and
the page number tells which type the object is.
Since a whole page of objects is allocated when only one
object is necessary,
the rest of the objects in the page are put on a free list.
This method of allocation is sometimes referred to as
.i bibop
for BIg Bag Of Pages.
The garbage collector for bibop is usually
a traditional
.i mark
and
.i sweep
algorithm.
All active data objects are marked and
then each page is swept linearly with
the free cells being put on the free list and the used cells
left alone.
The advantage of mark and sweep over a copying garbage collector is that
the mark phase is cheaper because data objects do not have to be copied.
Also, all of memory can be used since there is no requirement for two spaces.
The disadvantage is that a sweep phase is required in a mark and sweep
but one is not required in a copying garbage collector.
The sweep phase is expensive because it has to alter most data pages
while building a free list.
This operation
can be expensive in a virtual memory environment.
Alternatives to the sweep phase have been proposed in
[Foderaro+Fateman Characterization of Vax Macsyma].
.pp
.Fr
uses a bibop memory allocator and a mark and sweep garbage collector,
as does Maclisp (on a PDP-10).
The reason that
.Fr
uses bibop is primarily due to the VAX architecture,
which makes typed pointers
expensive to implement.
Also, typed pointers would make it difficult to pass lisp values
to programs written in other languages, some of which may not have
the ability to extract the address of a lisp object from a typed pointer.
.sh -1 Construction
.pp
The
.Fr
system is built by adding lisp code to a C-coded kernel.
The C-coded kernel is a working lisp interpreter, although it has few of
the functions a lisp system needs.
The lisp code provides most of the functions, the top level and error
handlers.
The lisp compiler is also written in lisp,
but is usually
run as a separate process.
.sh +0 Unique\ features
.pp
.Fr
can dynamically load and execute functions defined in the other languages
which run on the VAX.
It uses two different dynamic loaders.
One is part of the lisp system and is used for lisp only, it is called
.i fasl
(for fast loader).
The other is the Unix loader, ld, which is used for loading in
C, Fortran or Pascal code.
Loading code with fasl
is much faster than with ld
since fasl benefits from
the simplicity of a lisp object file.
.+c Data\ Structures
.sh 0 _
.nr $1 \n(ch
.pp
In this chapter we shall examine the data structures which are most
important to the
.Fr
system.
First, though we will see how the lisp system uses the address space.
.sh 2 Physical\ layout
.pp
As a Unix process, lisp has three address regions: text, data and stack.
Text begins at location 0 and continues up to 0x3b73c (0x means hex number).
The data segment begins on the next page boundary and continues
up to a limit set by the configuration parameters (currently 0x2fd000).
Lisp does not begin running with such a large data segment, rather it grows
when necessary.
The stack segment begins at address 0x7fffffff and grows downward to a
maximum size of one-half megabyte.
.pp
The text segment stores the instructions for the C kernel as well as read-only
data.
The read-only data for lisp are
the symbol nil, the i/o ports, and the small integer
table.
The symbol nil is stored at location 0 which makes it very easy to test
whether a value is nil.
The problem with storing nil in read-only space is that a special case
must be made for nil's property list, which is the only thing in the
nil symbol that the user is permitted to alter.
.pp
The fixnums -1024 through 1023 are stored sequentially, with 0 being
stored at 0x1400.
.Fr
doesn't have any 'immediate' lisp data, that is data whose value is
stored as part of the reference to the data.
But, by storing some of the fixnums in a known place, we can achieve
some of the benefits of immediate data:
A program can use
.i eq
as a test for a fixnum in the range -1024 to 1023.
In the majority of cases, when asked
to allocate a fixnum, the system can return a pointer into this table
and bypass the memory allocator.
.sh +0 Typetable
.pp
.Fr
uses the typed pages (or bibop)
method of type determination.
The
.i typetable
is an array of bytes (
.i chars
in C lingo).
This table describes the type of all pages, from page 0 where nil is stored,
up to the end of data space.
Thus there are many entries that describe the types of the pages which
make up the C kernel.
In order to reduce the wasted space in the typetable,
we could have made the typetable begin typing pages at the start of data
space and make a special case of the pages that contain nil and
the small integer table.
However, the
effect of this change would be that type checks
(which are done in-line in compiled code) would
be longer and slower. Since type checking happens quite
frequently, we felt it was better to waste the space in the
typetable in order to save execution time and instruction space.
.pp
Each page on a VAX is 512 bytes, and thus to find the type of an
object given the address of it,
it is only necessary to shift the address right 9 bits
and index the typetable array offset by one.
The offset by one is required because the value -4, which is an illegal
address, is used as a sentinel value to indicate an illegal value.
Thus when we take the type of -4 we will be indexing the table by -1
and we want to retrieve the first byte in the table (which contains
the value UNBOUND).
The C macro which retrieves the type is this (from file h/global.h):
.(b I
#define TYPE(a1) ((typetable+1)[(int)(a1) >> 9])
.)b
This is code generated by the lisp compiler to check if the type
code of an argument (stored at 0(r10)) is a symbol (which is type
code 1):
.(b I
ashl $-9,0(r10),r0
cmpb _typetable+1[r0],$1
.)b
.pp
The type codes which are stored in the typetable are these:
.ts 2i 4i 6i
.(b I
UNBO -1\tSTRNG 0\tATOM 1\tINT 2
DTPR 3\tDOUB 4\tBCD 5\tPORT 6
ARRAY 7\tOTHER 8\tSDOT 9\tVALUE 10
HUNK2 11\tHUNK4 12\tHUNK8 13\tHUNK16 14
HUNK32 15\tHUNK64 16\tHUNK128 17
.)b
The names given above are the C kernel internal names.
ATOM is symbol, INT is fixnum, DTPR is list cell,
DOUB is flonum, BCD is binary,
SDOT is bignum and all the HUNKn types are just known as hunk to
the user.
.sh +0 Stacks
.pp
.Fr
uses three stacks: the
.i C
.i runtime
stack, the
.i namestack
and the
.i bindstack .
The C runtime stack is the stack part of the address space
and the other two stacks are stored in the data space.
.sh +1 C\ runtime\ stack
The C-coded kernel uses this
stack in the same way as a typical C program
use the stack:
storing return addresses
and non-lisp-object arguments to subroutines,
saving registers,
and storing local variables within a function.
The lisp system stores
.i catch
.i frames
on this stack as well (to be described later).
.pp
The lisp system assumes that there are no lisp data on the stack and
thus the use of this stack
by a program is unrestricted.
As will be discussed later on, the
.b calls
and
.b ret
instructions are used for most subroutine calls and returns.
These instructions expect the stack to look a certain way.
.sh +0 Namestack
.pp
The namestack contains only lisp data.
It is used to pass arguments to functions and to hold
local (lexically scoped) data within lisp functions.
It is also used as a temporary storage spot for lisp data
which must be protected from garbage collection.
.pp
A slight digression on the garbage collector:
The person who writes code for the lisp system must always be aware of
his greatest enemy: the garbage collector.
Whenever a function is called that could possibly allocate more lisp
data, one must assume that it
when it attempts to allocate space, the garbage collector
will be invoked and that it will take away everything that isn't protected
from garbage collection.
The objects that are protected from garbage collection are: the
namestack, the bindstack, the oblist (table of interned symbols),
and the compiler literals. Objects that are only
referred to by values in registers or
the C runtime stack will not be seen by the mark phase of the
garbage collector and will be swept up during the sweep phase.
.pp
Back to the namestack:
The first free element on the namestack is pointed to by the
C variable
.i np .
This variable is always stored in the VAX register r6.
Another pointer into the namestack is the C variable
.i lbot .
It is always stored in VAX register r7.
Its use will be described in the section on calling conventions.
.sh +0 Bindstack
.pp
The bindstack is a stack of lisp object pairs: symbol and
value.
It is used to implement shallow binding.
When a symbol is lambda-bound, the symbol and its current value are put
on this stack.
Then the symbol can be given a new value.
When the context of the lambda binding is over, the symbol and value pair
are popped from the stack and the symbol is given its old value.
The C variable
.i bnp
points to the first free entry on the bindstack.
In the C code, the following macros lambda-bind a symbol to a value
and restore the old value:
.(b
#define PUSHDOWN(atom,value)\e
{bnp->atm=(atom);\e
bnp++->val=(atom)->a.clb;\e
(atom)->a.clb=value;\e
if(bnp>bnplim) binderr();}
#define POP\e
{--bnp; bnp->atm->a.clb=bnp->val;}
.)b
.sh -1 Bitmap
.pp
The bitmap is used in garbage collection to hold
the mark bits for the mark and sweep garbage collector.
As its names implies, it is viewed as a collection of bits.
The minimum size of a lisp data object is 4 bytes, thus
there are 128 of those on a VAX page of 512 bytes.
Since there are 8 bits in a byte, it takes 16 bytes to obtain 128 bits.
Therefore the size of the bitmap in bytes is 16
times the maximum number of
pages.
Like the typetable, the bitmap keeps track of marks from the
bottom of memory, not the bottom of data space.
The bitmap and the typetable are static structures.
It is their size, which is determined when the C kernel is built,
which determines the size to which the data segment can grow.
.sh +0 Transfer\ Tables
.pp
Transfer tables are used by compiled lisp code as a transfer vector to
other functions.
A transfer table consists of pairs of entries: symbol and pointer to
function.
When a compiled lisp function calls another (non-local) function, it
calls indirectly through an entry in the transfer table.
Depending on the setting of certain status variables, the call may
bring control into a function linkage routine or directly to
the function desired (if that function is a compiled lisp or C function).
.pp
Transfer tables serve a number of useful purposes.
.np
They allow compiled code to call interpreted code
or compiled code using the same calling sequence.
.np
They allow the selection of which function to call to be determined
at runtime based on the name of the function.
In most other languages, this selection process is done at either
compile or load time.
.np
They allow the user to run in a debugging mode where all calls
from compiled code go through the interpreter.
Once control reaches the interpreter, it is easier to debug.
.np
They allow the user to run in a production mode, where all calls
from compiled to other compiled code are done without function
lookup overhead.
.np
They allow the user to switch between debugging and production modes
at runtime with one function call.
.pp
Transfer tables will be described further in the section on
the lisp compiler.
.sh +0 Catch\ frames
.pp
Lisp has a number of forms of non-local transfers.
Among them are
.i throw ,
.i error ,
.i return
and
.i go .
If a program is willing to accept a non-local transfer, it puts a
.i catch
.i frame
on the stack which describes which type of transfer it
accepts.
The catch frame describes the current state of the registers,
the variables np, lbot, and bnp, and also contains entries that describe
what kinds of non-local transfers the function will accept.
After creating a catch frame, the program goes on to evaluate forms.
Should the evaluation of one of those forms result in a non-local
transfer to the catch frame that this program has set up, the
system will restore the namestack and bindstack to the way
they were when the program put the catch frame on the stack (by using
np and bnp) and will return control to the program (setting
the variable retval to describe why it returned).
This is described further in the
section on interpreter conventions.
.pp
The C variable
.i errp
points to the most recent catch frame, and then each catch frame points
to the previous catch frame.
.sh +0 oblist
.pp
Normally when symbols are created they are
.i interned ,
that is they are put in a hash table called an oblist (or obarray).
The purpose of the oblist is to insure that if you type a
symbol's name to the reader, you will always get the same symbol.
Also it protects the symbol from garbage collection.
The oblist is simply a hash table with buckets, with a hash link being
part of the symbol data structure.
Currently the hash table is not accessible to a lisp program, but with
a little work it could be.
.+c Interpreter
.sh 0 _
.nr $1 \n(ch
.pp
The interpreter is composed of these parts:
.ip \fIcore:\fP
The functions eval, apply and funcall.
.ip \fIstack\ management:\fP
The code to create catch frames and handle non-local transfers.
.ip \fImemory\ management:\fP
The code to allocate and garbage collect memory.
.ip \fIthe\ functions:\fP
The user callable functions that expect lisp arguments and return
lisp values.
.pp
In the above list, the first three are written mainly in C (with a little
assembler) and the last is written mainly in Lisp with a little
bit in C
and a very small amount in assembler.
.pp
The core functions are the center of activity in the interpreter.
The
.i eval
function given a lisp expression to evaluate.
It must determine if it is a simple expression such as a symbol or number
whose value eval can determine immediately, or if it is an function
calling expression.
If the form is a function call, eval must determine if the arguments should
be evaluated and if so eval must recursively call itself to evaluate the
arguments and then stack them.
If the function called is to be interpreted, eval must lambda-bind the
formal variables of the function to the arguments just stacked.
If the function being called is compiled, eval just calls the function and
lets the function do the lambda binding if it wants to.
.pp
The
.i apply
function is passed two lisp objects:
a function to call (either a symbol or a functional object)
and a list of arguments already evaluated.
It will do lambda binding if the function to call is to
be interpreted.
.pp
The
.i funcall
function is passed any number of lisp objects,
the first of which is the function to call, and the rest are the
arguments to the function
which have already been evaluated and stacked.
Funcall will do lambda binding if the function to call is
to be interpreted.
.pp
When compiled lisp code calls a function
which must be interpreted, it enters the interpreter through the
funcall function.
The interpreter may go to compiled code through either eval, apply or
funcall, though most often it goes through eval.
.sh 2 Conventions
.pp
These are the conventions used in interpreted and compiled code.
.sh +1 C\ conventions
.pp
Our conventions are extensions of the C calling conventions, so we
describe here the conventions for C.
The VAX has 16 general
purpose registers.
Registers r12 through r15 are reserved
for use by the hardware because we use the
.i calls
subroutine call.
Registers r0-r5 can be used by a program without saving them first.
The result of a function call is returned in r0.
Registers r11-r6 are allocated (from high to low)
by the C compiler when a
.i register
declaration is made in the C code.
Registers r11-r6 must be
saved upon entry and restored upon exit if they are used within a function.
On the VAX it is very easy to preserve registers
since it is done automatically
by the hardware if the
.i calls
(or
.i callg )
instruction is used.
The first short word (two bytes) of a subroutine is a
register save mask which
tells which registers should be saved (on the C runtime stack) upon
entry and restored when a
.i ret
instruction is done.
.sh +0 np\ and\ lbot
.pp
Earlier we mentioned that the C variables np and lbot are
always stored in
registers r6 and r7.
It is very difficult to globally assign a variable to a register
in the C language (no external register declarations
are permitted)
and thus we have to filter
the output of the C compiler and convert all occurrences of 'np' to 'r6'
and all occurrences of 'lbot' to 'r7'.
This is only half the job, though.
We also must modify the register save masks for those routines which
alter the value of np or lbot to insure that those registers get
saved and restored upon function entry and exit.
This is done in the C code by putting
.(b C
Savestack(n)
.)b
at the beginning of a routine which will alter np or lbot and which
also allocates n register variables.
Also in that routine, before the function returns, we put
.(b C
Restorestack()
.)b
This is not really necessary in the VAX, but it is there for other
machine implementations which don't have a
.i ret
function which restores registers.
The calls to Savestack are recognized by a filter which processes
the output
of the C compiler and fixes up
the save masks.
.sh +0 Function\ calling
.pp
The following text describes what the conventions are for
calling
compiled lisp functions, whether they were written in lisp or C.
We look at it from the viewpoint of the called function.
.pp
Upon entry
to the compiled functon,
lbot points to the first argument and np points to the
first free spot on the namestack.
If np equals lbot then there are no arguments.
Recall that np will be in r6 and lbot in r7.
The function is free to alter registers r0 through r5 and should return
the result in r0.
The function may alter registers r6 through r11 as long as their
original values
are restored when the function returns.
The value of np should always
point to the first free entry in the namestack.
This is all that is required.
The extra conventions followed by
the lisp compiler
in the code it generates are described in the next chapter.
.sh +0 Catch\ frames
.pp
A catch frame saves the state of execution that a program
might want to return to at some later time.
A catch frame is stored on the C runtime stack, with the most recent
frame pointed to by the C global variable errp.
The information saved is
.ip \fIargs\fP
- one or two optional arguments. The lisp compiler always
stacks two
arguments since it must know exactly how large the frame is.
.ip \fIclass\fP
- the class describes what type of frame this is (described below).
.ip \fIretaddr\fP
- address to return to if returning from this frame
.ip \fIolderrp\fP
- pointer to next older catch frame on the stack
.ip \fIbnp\fP
- value of bnp (bindstack pointer) when the frame was created
.ip \fInp\fP
- value of np when the frame was created
.ip \fIlbot\fP
- value of lbot when the frame was created.
.ip \fIsystem\ dependent\fP
- the rest of the information stacked depends on the particular machine.
In the case of the VAX, registers r13 through r8 are stacked. (r14 and
r15 are the stack pointer and program counter; they are not saved since
they can be calculated from the other information).
.pp
The information in a catch frame is put on the C runtime stack
in the precise order given above, and the variable errp points not
at the beginning of the entire frame, but to the lbot entry.
Thus errp\ +\ 4 points to np.
The classes of frames are described below.
Each class is defined as a constant in the C code (h/frame.h) whose value
is a small integer.
.ip F_PROG\ [1]
- takes no arguments. This frame marks the beginning of a piece of
code which can accept a
.i return
or a
.i go .
The interpreter uses this to implement
.i prog
and
.i do
and for its primative break loop.
The lisp compiler does not use catch frames for progs since it only
permits
.i returns
and
.i gos
to occur within
.i progs
or
.i dos
and thus it can determine how to do the non-local transfer
at compile time.
.ip F_CATCH\ [2]
- this takes one or two arguments and is used to implement both
.i catch
and
.i errset .
In both cases
the first argument is the tag which is being caught,
which in the case of an
.i errset
is symbol ER%all.
An
.i errset
also
supplies a second argument which is non nil if the error message
should be printed.
.ip F_RESET\ [3]
- in the C kernel, the reset function
is implemented as a non local transfer to a F_RESET catchframe.
When the lisp system is built, the reset function is redefined to
do a
.i throw.
Thus this type of catch frame is rarely used.
.ip F_EVAL\ [4]
- this has one argument, the form being evaluated.
Since stacking this
on every eval would be expensive,
this type of catch frame is only stacked if a \fI(*rset\ t)\fP
has been done and if the value of the symbol
.i *rset
is non nil.
The form being evaluated is stacked so that
the necessary information for the
.i evalframe
function is available and so that
.i freturn
can return from the context of any pending evaluation.
.ip F_FUNCALL\ [5]
- this is much like F_EVAL,
except the one argument it takes is the
name of the function to call.
It has the same restrictions on when it is stacked as F_EVAL
and for the same reasons.
.pp
In C, a frame is pushed on the stack with Pushframe, with a call
of one of these forms:
.(b
errp = Pushframe(class);
errp = Pushframe(class,arg1);
errp = Pushframe(class,arg1,arg2);
.)b
After the call the C variable
.i retval
contains the value which describes why this function returned.
You must remember that it is possible for this one function call to
return more than once!
The reasons it can return are these (from h/frame.h):
.ip C_INITIAL\ [0]
This is the initial call to set up the frame.
.ip C_GO\ [1]
This will only happen for F_PROG frames.
In this case,
the C variable lispretval contains a lisp symbol which is the tag
to which control should be transferred.
If the tag cannot be found in this prog or do body, the
tag should be again thrown up the stack to a next higher prog or do.
.ip C_RET\ [2]
This will only happen for F_PROG frames.
In this case, lispretval contains the value to return from this prog.
.ip C_THROW\ [3]
This will only happen for F_CATCH frames.
In this case lispretval contains the value to return from this catch.
.ip C_RESET\ [4]
This will only happen for F_RESET frames.
It simply means that a reset is being done.
.ip C_FRETURN\ [5]
This will only happen for F_EVAL and F_FRETURN frames.
The variable lispretval contains the value to return from this
call to
.i eval
or
.i funcall .
.pp
The call to Pushframe is turned into a simple subroutine call (using
the
.i jsb
instruction instead of the
.i calls )
by the filters which alter the code coming out of the C compiler.
Thus it may be useful to see what stacking a catch frame really looks
like.
Here is what the lisp compiler generates
to stack the frame for \fI(*catch\ 'tag\ x)\fP
.(b
movl 0(r8),r0 #move 'tag to r0
pushl $0 # dummy argument
pushl r0 # put tag argument on C runtime stack
pushl $2 # push F_CATCH
jsb _qpushframe # call Pushframe
movl r0,_errp # move result into errp
.)b
.pp
Every function which does a Pushframe() must also do a Popframe()
before it returns to its caller.
This simply removes the frame from the stack.
In C it is written:
.br
.tl ''errp = Popframe()''
in the code generated by the lisp compiler it looks like:
.(b
movl _errp,r1 # put current errp in r1
movl 12(r1),_errp # put previous errp in errp
addl3 $32,r1,sp # pop frame from stack
.)b
.pp
Non-local transfers are done with the Inonlocalgo
function. This function always takes three arguments.
The
first is the return type (one of the types mentioned
above which begin with 'C_'). It will be assigned to retval.
The second argument is the value to be assigned to lispretval,
except in the case of a C_THROW, where the second argument
is the tag to throw to and the third argument is the value
to assign to lispretval.
This function never returns.
If it doesn't find a catch frame
which matches what it is looking for, it signals an error.
The function is called with
.i calls
and the arguments are stacked on the C runtime stack, not the
namestack.
.+c Liszt:\ The\ Lisp\ Compiler
.sh 0 _
.nr $1 \n(ch
.pp
The purpose of compiling a lisp function is to create a representation of
the function which can be evaluated in less time and perhaps take
up less space.
There are two approaches to lisp compilers.
One is to convert the functions to a compact form, often called
.i bytecodes
which can be rapidly interpreted.
Each bytecode represents a primitive operation in the lisp system.
This approach is simple to implement but there is an time penalty
in using an interpreter.
The other approach is to compiled to machine code.
In general, this is not as portable as the bytecode approach but the result
generally runs faster.
There are two ways of compiling to machine code.
One is to place arguments to functions in registers.
If there are more arguments than registers, the arguments are put on
a stack and a special type of call is made.
This method is used in Maclisp.
The other method is to assume a stack model, in which
arguments to a function are placed on a stack.
This is what the
.Fr
compiler Liszt does.
The stack model made it much easier to write parts of the lisp
system in the C langauge.
It also simplifies the garbage collector since the mark phase doesn't
have to locate and peruse all saved registers looking for lisp data.
.sh 2 File\ Compiler
.pp
When a file of lisp expressions is loaded,
the
.i load
function repeatedly reads and evaluates the forms in the
file.
Some of these evaluations may result in functions being defined,
and others may use the functions just defined or previously defined.
The job of the lisp compiler is to create an object file, which,
when read in
by
.i fasl,
acts just like it was
.i load ed
in, except when a function is defined it is defined in machine
code, not as a lisp expression.
This is quite a bit different from what compilers do in other languages
and it is done this way to make it easier to
switch between compiled and
interpreted code.
.sh +0 Differences\ between\ compiled\ and\ interpreted
.pp
There are some differences, though, between compiled and interpreted code.
Local variables in compiled code are lexically scoped (put on the
namestack and inaccessible to other functions) unless the variable
has been declared
.i special.
The declaration:
.(b
\fI(declare (special x y))\fP
.)b
declares both x and y to be special from this point in the file on.
The declaration
.(b
\fI(declare (specials t))\fP
.)b
declares all variables to be special.
.pp
Lisp has a very powerful macro definition system.
The compiler will macro expand all it can, whereas the interpreter
expands macros when necessary but never replaces a macro call with
its expansion.
Thus if you redefine a macro, the compiled code that uses it will
still work the same way, but the interpreted code will use the
new definition.
Also, when compiling a file, macro definitions must be
done before any call on the macro is encountered during compiling.
In the interpreter,
macros can be defined or redefined anytime up until
they are used.
Thus the interpreter is far freer about macro definitions than
the compiler.
This could cause programs which work interpreted to
fail compiled.
.sh +0 Top\ level\ algorithm
.pp
The top level algorithm of the compiler is simply this:
.np
read a lisp expression from the input file
.np
macro expand the top level of the form as much as possible
.np
if the form is a function definition (a list beginning with
the symbol 'def')
then compile it.
.np
if the form is not a function definition then put it on a list of
forms that will be evaluated when the file is
.i fasl ed
in.
.np
if not at end of file, go to step 1.
.pp
In reality, step 3 is a bit more complex.
If the definition is of a macro, then the form will be evaluated
immediately, thus adding the macro definition to the compiler's
environment.
If the lisp variable
.i macros
is t then the macro will also be compiled.
There are also some forms like \fI(progn\ 'compile\ ...)\fP
and \fI(eval-when\ ()\ )\fP which determine when the
forms get compiled and evaluated.
See the lisp manual for details.
.sh +0 Expression\ Compilation
.pp
Just as the interpreter is centered around the
.i eval
function, the lisp compiler is centered around the function
.i d-exp
whose job it is to compile the expression passed to it.
The lisp compiler is one pass.
Before a call to d-exp returns,
all the compiled code for a form has been computed and written
to a file.
One reason that the lisp compiler can be a single pass compiler
is that the assembler which reads the compiler's output is
a two pass assembler.
.sh +1 global\ state\ variables
.pp
There are a number of variables that maintain the state of
the compilation process.
These variables are declared special and are thus dynamically scoped
and visible to any function within the compiler.
When d-exp
is called their meanings are:
.ip \fIv-form\fP
- contains the expression to be compiled.
.ip \fIg-loc\fP
- tells where the result of evaluating this expression should be put.
If g-loc is nil, then the value returned is unimportant and shouldn't
be put anywhere.
.ip \fIg-cc\fP
- controls conditional branches.
If g-cc is non nil, then it is a list cell whose value has
either a non-null car or non-null cdr but not both.
If the car is non-nil then
if the value of the expression held in
v-form is non-nil, a branch should be done to the symbol
stored in \fI(car\ g-cc)\fP.
If the cdr is non-nil then if the value of v-form
is nil, a branch should be done to the symbol stored in
\fI(cdr\ g-cc)\fP. Since at
every conditional
branch control should either jump or continue, the car and cdr will
never both be specified.
.ip \fIg-ret\fP
- is non nil if the result of evaluating v-form will be returned as the
value of the function we are evaluating.
This is used to allow liszt to detect
when tail recursion removal is possible.
.ip \fIg-locs\fP
- maintains current information about the state of the stacks:
the bindstack (for specials), the namestack (for locals) and the
C runtime stack (for catch frames)
The form of g-locs is a stack of tokens stored as a list.
The meaning of each token is as follows:
.br
\fInil\fP - this represents an unnamed object on the namestack. This happens
when calling functions, when the arguments are stacked prior
to a function call.
.br
\fI<symbol>\fP - the given symbol is the name of a local variable on the namestack.
.br
\fI(prog . <n>)\fP - prog statement which binds <n> special variables
.br
\fI(do . <n>)\fP - head of a do statement which binds <n> special variables
.br
\fI(catcherrset . 0)\fP - catch or errset frame on stack
.br
\fI(lambda . <n>)\fP - lambda expression which binds <n> special variables
.ip \fIg-labs\fP
- this is a stack of labels.
There is one entry in g-labs for every entry which is a list
in g-locs.
the forms of the entries are:
.br
\fInil\fP - no labels in this form
.br
\fI(endlab (real . gen) (real2 . gen2) ...)\fP - endlab is the label to go to
to get out of this body. After this label will be code
to unbind specials and pop off locals.
The 'real' labels are those found in the code. the gen
labels are those generated and put in the assembler code.
.sh +0 Function\ compilation
.pp
The action d-exp takes when compiling an expression depends on the
type of expression.
For atoms (symbols and numbers) the compilation is very simple, it
is just a matter of putting the value where g-loc specifies and
then jumping if specified by g-cc.
When the expression is a list, d-exp first macro
expands the form and then looks at the first element of
the list (if the list has not macro expanded to an atom).
If the first element is a symbol then the list is
is a function call.
If the function is one of the functions which liszt knows how to open compile
then liszt will call the particular routine designated to open
compile this function.
There are two classes of functions within liszt that
do open compiling.
The first class, the fl-expr class, are distinguished by names which
begin with c-.
These functions always generate
code which returns the result in r0.
They are not equipped to obey the contents of g-loc and g-cc.
Thus d-exp, after calling one of these functions, must do what
is necessary to obey g-loc and g-cc.
The other class of open compiling functions, the fl-exprcc class (whose
names begin with cc-),
handle g-loc and g-cc.
As a result these are usually much more complex and generate better code.
.sh -1 Register\ Conventions
.pp
The register conventions used by liszt are an extension of those
used by the C code.
.ip \fIr0\fP
- return value placed here
.ip \fIr1,r2,r3,r4\fP
- scratch registers.
When long strings of
.i car's
or
.i cdr's
are done (such as
.i caddadr )
these registers are used in a least-recently-used fashion to access down
the list.
The compiler keeps track of the values in these registers but must
assume that they are garbage after a function is called.
.ip \fIr5\fP
- fixnum accumulator.
There a number of functions which work on fixnum's only and these
usually put their result in r5.
The assembler code function
.i qnewint
which returns a pointer to a cell containing a fixnum value (after
checking if it is in the fixnum table), expects its argument to be
in r5.
.ip \fIr6\fP
np
.ip \fIr7\fP
lbot.
When calling a function, this register is set just before the function
call, and after the function call its value is used to reset the value
of np in order to pop the arguments off the namestack.
.ip \fIr8\fP
the literal table pointer.
The compiler generates a table of all the literal lisp data
which the compiled code might access.
Upon function entry a pointer to the base of this table is put in r8.
For example, if we compile \fI(setq\ x\ 'foo)\fP then we will
need a pointer to the lisp symbol
.i foo
and if the symbol
.i x
as been declared special we will also need a pointer to
.i x .
.ip \fIr10\fP
- upon function entry the value of lbot (r7) is put in r10.
This allows us to reference the arguments to our function while
using lbot to call other function.
.sh +0 Addresses
There are four types of addresses used internally in Franz:
symbolic, intermediate addresses (iadr), extended intermediate (eiadr)
and vax assembler format.
.sh +1 Symbolic
.pp
These are the names of lisp objects, such as `a', `foo', 34,
or 3.234234.
A name is either a local variable, a special variable or a
number. A number is either a small fixnum, large fixnum,
bignum or floating point number.
.sh +0 Intermediate\ address\ (IADR)
.pp
This type of address is generated from a symbolic address by
.i d-loc,
.i d-loclit
and the routines
.i d-simple
and
.i d-rsimple
which
call them. The forms are
.ip \fINil\fP
- the location or value of nil.
.ip \fIT\fP
- the location or value of t.
.ip \fIreg\fP
- register r0, which is where the result of function calls
are stored.
.ip \fIstack\fP
- the address pointed to by np with np incremented after
the value is stored. (i.e (r6)+)
.ip \fIunstack\fP
- the address one word below np (np is decremented before
accessing. (i.e. -(r6))
.ip \fI<symbol>\fP
- this is just <symbol>. This allows strange forms to be
represented directly.
.ip \fI(stack\ n)\fP
- The n'th value on the namestack for this function.
The first value 0(r10) is (stack 1).
.ip \fI(vstack\ n)\fP
- The cdr of the n'th value on the namestack.
That is, (stack 1) is *0(r10)
.ip \fI(bind\ n)\fP
- The value of the n'th value in
the literal table. If
this refers to a symbol, then this is the value
of the symbol.
If this refers to a list then this
this is the cdr of the list (although this is a rare
use). (bind 1) corresponds to *0(r8).
.ip \fI(lbind\ n)\fP
- The n'th value in the literal table. If
this refers to
object foo then this is the address of foo
in memory.
.ip \fI(fixnum\ n)\fP
- This is the address of small fixnum n in memory.
A small fixnum is in the range -1024 to 1023.
.ip \fI(immed\ n)\fP
- The is the immediate constant n.
.sh +0 extended\ intermediate\ address\ (EIADR)
.pp
This address is generated from an IADR by e-cvt. It
symbolically represents a vax address.
.ip \fI<atom>\fP
- This corresponds to <atom>.
.ip \fI(n\ <atom>)\fP
- This corresponds to n(<atom>)
(stack n+1) and (lbind n+1) are converted to these forms.
.ip \fI(n\ <atom1>\ <atom2>)\fP
- This corresponds to n(<atom1>)[<atom2>]
There is currently no IADR which generates this.
.ip \fI(*\ n\ <atom>)\fP
-This corresponds to *n(<atom>)
(vstack n+1) and (bind n+1) are converted to these forms.
.ip \fI(+\ <atom>)\fP
- This corresponds to (<atom>)+.
stack is converted to this form.
.ip \fI(-\ <atom>)\fP
- This corresponds to -(<atom>)
unstack is converted to this form.
.ip \fI($\ <numb>)\fP
- This corresponds to $<atom>
(immed <numb>) is converted to this form.
.ip \fI(#\ <numb>)\fP
- This corresponds to $<loc> where <loc> equals
the base of the fixnums (0x1400) plus 4 * <numb>
(fixnum <numb>) is converted to this form
.ip \fI(*\ #\ <numb>)\fP
- This corresponds to $<numb>. It is generated
by d-rsimple occasionally when you ask for the
cdr of a number (which you do sometimes when you
are compiling fixnum operators).
.sh +0 Vax\ Unix\ assembler\ addresses
.pp
The addresses are printed from a EIADR by e-cvtas. The conversions
are shown in the above section.
.sh -1 Function\ calling\ convention
.sh +1 Function\ linkages
.pp
The function associated with a symbol is stored in the function
definition slot of the symbol. If the function slot contains a
list then the function is to be interpreted and its 'car' will
be lambda, nlambda, lexpr or macro. If the function is compiled then
the function definition slot will contain a binary object.
A binary object
is composed of two independent parts: the discipline and the entry.
The discipline is one of:
.ip \fIlambda\fP
- a function whose arguments should be evaluated.
.ip \fInlambda\fP
- a function whose arguments should not be evaluated but
which should be passed as a list
.ip \fImacro\fP
- a function which should be passed the unevaluated form
being evaluated and whose result should be evaluated.
.ip \fI\"subroutine\"\fP
- a foreign function subroutine
.ip \fI\"integer-function\"\fP
- a foreign function returning an integer
.ip \fI\"real-function"\fP
- a foreign function returning a flonum.
.pp
A lexpr is not in the list as there is no difference to the caller
between compiled lambda's and compiled lexprs.
.sh +0 Transfer\ tables
Most calls from compiled code to other lisp functions go through
transfer tables. A transfer table entry is a pair: symbol, address
of routine.
When another lisp function is called it uses the
.i calls
instruction which will
indirectly jump through the address in the transfer table. This
address may point to the desired function or it may point to the
interface routine. If a call ends up in the interface routine,
then that routine will trace back through the call stack and eventually
reach the tranfer table entry that it was 'called through'. Since the
transfer table entry contains a symbol which names the function
to be called, the interface routine can determine which routine
was to have been called. If that routine is compiled then the
interface routine can modify the transfer table so that a call
through that table entry will go directly to the desired function.
If the routine to be called is interpreted, or if the user has
requested that transfer linkages should be disabled, then the
interface routine will go through the 'funcall' function
in the interpreter to continue the call.
.sh +0 calling\ sequence\ in\ the\ compiler:
.pp
When transfer tables are used
.(b
\fBforeach\fP arg
\fBcompute\fP arg and stack result using (r6)+
for example: movl r0,(r6)+
movab -n(r6),r7 where n = 4*number of args to fcn
calls $0,*trantb+m where m is the index of the function
in the transfer table.
movl r7,r6 restore r6
.)b
.pp
The compiler supports local functions, which are function accessible
only within one file.
Because they are not accessible from C code, we can use a very fast
call and return sequence when calling them.
To call a local function
.(b
\fBforeach\fP arg
\fBcompute\fP and stack using (r6)+
jsb LOCALNAME go directly to the function, it will
restore r6 before it returns.
.)b
.pp
The beginning of each function looks as follows.
First for a non-lexpr function called in the standard way
(topsim is the label jumped to when tail merging, it will be unique
for each function; the brackets indicate the optional code which
exists if the -p switch is given to liszt);
.(b
.word 0x5c0 # save r6, r7, r8, r10
[ movab mcounts,r0 # if profiling, mcounts replaced by fasl
jsb mcount ]
movab linker,r8 # set up r8
movl r7,r10 # set up oldlbot
movab n(r10),r6 # n = 4*Number of args expected.
topsim:
.)b
.pp
Now for lexprs:
.(b
.word 0x5c0
[ movab mcounts,r0 # if profiling. [mcounts replaced by fasl]
jsb mcount ]
movab linker,r8 # set up r8
subl3 $4,r7,-(sp) # address one word below bottom of args
topsim:
movl r6,r10 # first free addr to arg base
subl3 r7,r6,r0 # number of args * 4 into r0
movab 0x1400(r0),(r6)+ # stack boxed number of args
movl 0(r10),-(sp) # also store on stack so user can't clobber
.)b
.pp
And finally for local functions:
.(b
movl r10,-(sp) # save r10
movab -n(r6),r10 # set up arg base using arg top
topsim:
.)b
.sh -1 Assembler\ file\ format
.pp
The liszt compiler generates a file which is in Unix assembler format.
The Unix assembler converts that file into an object file which fasl
then reads.
Although the object file generated is a standard Unix object
file (as defined in /usr/include/a.out.h), it is not of a
format that the Unix ld loader can understand.
This is because the requirements of a lisp object file are different
from an object file of other languages.
The
run time semantics of lisp and the fact that lisp data must be protected
from garbage collection are the principal differences.
The unconventional object file created by the unix assembler
is a result of the
unconventional assembler input file.
Next we will look at what must be put in the assembler file and how
it is put there.
.pp
The assembler file must contain
.ip \fIinstructions\fP
- vax assembler code for the compiled functions.
If there aren't any functions compiled, this can be empty.
.ip \fIliterals\fP
- lisp data which is referred to by compiled code
.ip \fItransfer\ table\fP
- the names of the functions which correspond to the calls through
the transfer table.
The instructions simply say 'call indirect through the nth transfer
table entry'.
.ip \fIfunction\ names\fP
- the names of the functions which are being
defined.
.ip \fIload\ time\ forms\fP
- in order to mimic the
.i load
function, fasl has to be able to evaluate lisp expressions at fasl
time, so we must be able to store lisp expressions in the assembler
file and indicate when they should be evaluated.
.pp
Based on the requirements above, the form of the assembler file
is as described below.
The assembler builds two segments: text and data.
We put all of our information in the text segment.
The compiler places some annotation strings in the data segment
so that the object file can be identified, however the data segment
is ignored by fasl.
The format is
.ip \fIcompiled\ instructions\fP
The instructions for each compiled (non-local) function begins with
.(b
.globl F00003
F00003:
.word 0x5c0
.)b
The globl declaration and the fact that the symbol name begins
with a F will tell fasl that this is the beginning of a lisp
function.
The symbols beginning with F must be unique within a file
but may be duplicated in other files.
The lisp name of the function will appear later.
Next the instructions for the function are given.
Only a small fixed set of external symbols may be referenced.
The list is found in the code for nfasl.c and the common
ones will be described below (soon).
Labels should be given a name beginning with L and should
be unique within the file.
.ip \fItable\ sizes\fP
somewhere in the file there should be a pair of 'set' assembler
pseudo ops which describe the sizes of the literal table and
transfer table.
The form is this
.(b
.set linker_size 4
.set trans_size 3
.)b
where linker_size is the number of entries in the literal table
which will be required and trans_size is the number of entries
in the transfer table which will be required.
Those tables will be built by fasl.
.ip \fIbinder\ table\fP
- this table describes the order that the functions should be
defined and forms evaluated.
It is a table of longwords beginning at the symbol bind_org
and ending when a -1 entry is seen.
The meaning of the entries will be described below.
.ip \fIlisp\ expression\ table\fP
- this is a table of null terminated strings beginning at the
symbol lit_org and ending at the symbol lit_end.
Each string is read by the lisp read function (using the
raw readtable).
The first linker_size expressions are put in the literal table.
The next trans_size expressions are the names of the
functions to put in the transfer table.
The remaining expressions correspond to the entries in the
binder table.
The binder entries are processed, one by one.
Provided that the binder entry is not -1, an expression
is read from the lisp expression table.
Then if the binder table entry is 0, that expression is the name of
a lambda type lisp function.
A binary object is created, the discipline is set to lambda and
the function address is set to the lexically next function
defined in the
file.
If the binder entry is 1 then this is an nlambda function, and
if the entry is 2 then this is a macro function.
If the entry is 99 then the expression just read should be evaluated
by the lisp function eval.
.pp
The lisp compiler normally puts the assembler format output file in /tmp
and removes it when it is done.
The -S switch will tell liszt to write the
assembler file in the same place as
the source file, and with the same root name but a .s extension.
The -C file will tell the lisp compiler to comment the file as it
generates it, making it easier to understand what is going on.
Assume that the following is file foo.l:
.(b
(defun foo (x) (bar y) (baz k))
(print (foo 3))
(def test (nlambda (l) (print 'hithere) (foo 3)))
.)b
we now compile it with -SC
.(b
.globl F00007 #(fcn lambda foo)
F00007:
.word 0x5c0
movab linker,r8
movl r7,r10
movab 4(r10),r6
L00008:
movl *0(r8),(r6)+ #(calling bar)
#(from y to stack)
movab -4(r6),r7
calls $0,*trantb+0
movl r7,r6
movl *4(r8),(r6)+ #(calling baz)
#(from k to stack)
movab -4(r6),r7
calls $0,*trantb+8
movl r7,r6
ret
.globl F00009 #(fcn nlambda test)
F00009:
.word 0x5c0
movab linker,r8
movl r7,r10
movab 4(r10),r6
L00010:
movl 8(r8),(r6)+ #(calling print)
#(from 'hithere to stack)
movab -4(r6),r7
calls $0,*trantb+16
movl r7,r6
movl $5132,(r6)+ #(calling foo)
#(from (fixnum 3) to stack)
movab -4(r6),r7
calls $0,*trantb+24
movl r7,r6
ret
bind_org:
.set linker_size, 3
.set trans_size, 4
.long 0
.long 99
.long 1
.long -1
lit_org:
.asciz "y"
.asciz "k"
.asciz "hithere"
.asciz "bar"
.asciz "baz"
.asciz "print"
.asciz "foo"
.asciz "foo"
.asciz "(print (foo 3))"
.asciz "test"
lit_end:
.data # this is just for documentation
.asciz "@(#)Compiled by Lisp Compiler 7.1 on Sun Feb 21 17:51:54 1982"
.asciz "@(#)decl.l 1.5 2/10/82"
.asciz "@(#)array.l 1.1 9/25/81"
.asciz "@(#)datab.l 1.1 9/25/81"
.asciz "@(#)expr.l 1.1 9/25/81"
.asciz "@(#)io.l 1.1 9/25/81"
.asciz "@(#)funa.l 1.3 2/10/82"
.asciz "@(#)funb.l 1.2 2/10/82"
.asciz "@(#)func.l 1.2 2/10/82"
.asciz "@(#)tlev.l 1.4 10/24/81"
.asciz "@(#)fixnum.l 1.6 10/21/81"
.asciz "@(#)util.l 1.2 10/7/81"
.)b
.sh +0 functions\ callable\ from\ compiled\ lisp\ code
.sh +0 Object\ File\ Format
.sh +0 Fasl