The Stacks

As it was explained in the introduction, this implementation is not a stack oriented one. That means the argument passing in evaluations are not performed via a stack but through some fixed memory locations (registers). This fact, should in no means be interpreted as no stack is used at all. Indeed, there exist basically three different stacks in this implementation.

The System Stack

This stack is provided by the C compiler and is the place where all the C local variables --or so called auto's-- are created, arguments are passed on, the functions return addresses are pushed on. The system is designed not to interfere with this stack. We tried to refrain passing LISP objects as arguments on this stack, and if we have done so, it was in those cases where we were absolutely sure that no garbage collection marking would be necessary for those entities.

The SEXPR Stack

In fact this is not a stack where the S-expressions are pushed on but merely a stack where pointers to S-expressions are pushed on. A language like LISP, that provides recursion must definitely have a stack where domain entities of it can be pushed. It is implemented as an array of PSEXP's and is has its start pointed by the variable zstackptr and its current top pointed by the variable zstacktop . There exist define macros that serve to load to/from this stack from/to the registers and macros to move the top-pointer: (kalloc(), ksetn(), kloads(), ksets() ). They will not be explained here in details, the code is self-explanatory. It is for sure that a garbage collection marking is performed from this stack. The array that is used for this purpose is either allocated as a static array at compile time or is allocated dynamically from heap at the initialization of LISP. The way chosen depends on the the state the compiler flag #DSTACK is set to, at compile time of the LISP system. If it is to be allocated dynamically then the default size can be overridden by a command line option.

The ALIST stack

This stack is used for the lambda and prog bindings. Especially in the interpretive environment the user defined lambda expressions and prog's are of intense use. Every time a identifier is used as a lambda variable or a local variable for a prog body the LISP system has to save the old value of that identifier, in order to be able to restore it upon the exit. The implementation of the stack is realized as an array of data structures (named ALISTENT) of the following form.

Similar to the SEXPR stack it is possible to allocate this stack in the static area or dynamically depending on the same compiler flag. The start of this stack is pointed by the variable alist and the top is pointed by alisttop.