Notes on LISP 2 listing
Jeff Barnett. Notes on LISP 2 listing. June 2010.
by Jeff Barnett
These notes serve as a table of contents for the Lisp 2 listing. Each bookmarked section in the PDF file corresponds to one source file of the system. Each file comprises a list of lists. Each top-level list starts with a name and is followed by a sequence of top-level declarations and definitions. Lisp 2 needs declarations for referenced objects to successfully compile because numbers are represented differently than pointer objects. All objects in a top-level list can freely reference each other. If we were better able to scan the listing and perform character recognition, the presentation of the listing would be a list of the top-level lists rather than a list of files. The grouping into files is, however, reasonably logical and the description of each file tries to cover all top-level lists as if they really belonged together.
- Basic objects needed to compile the system itself. The runtime needs several pieces of low-level system code placed at fixed locations (i.e. known at compile time). Examples are code to bind/unbind global variables and manage the push down stacks. Several global variables used for communication and primitive functions are declared also. Consider this file as an open bracket, closed by file POSTCOMP. The order of code in the brackets is often critical since the core image generator has to “learn by doing.”
- GARBAGE COLLECTOR
- Variables, functions, and declarations that are part of the garbage collector.
- HODGE PODGE
- Contains basic declarations and low-level routines of all sorts: decs for some error handling and IO primitives; macros to access pieces of memory; decs of space boundaries and active pointers; primitive type predicates; “equal” implementation; basic array, list, string, and identifier allocation and adjustment primitives; simple arithmetic and bit processing routines the compiler can link to; some type converters; low-level error routines; low-level storage allocation and free; predicate to determine if a symbol expression is a type; symbol to/from interior type specifications; install quoted expression in image; generate errors on bad type specs.
- Implementation of the system I/O.
- TOKEN PARSER
- The finite state machine implementation to parse tokens.
- SYS FUNCTIONS
- Declarations for I/O, miscellaneous functions, low-level implementations, error trap and trace logic, binary program space management, dump compilation to disk, load it back, and more.
- Implementation of the Lisp Assemble Program (LAP).
- Captures some of the storage allocation pointers and the contents of the oblist (the identifier hash) at the point this file is compiled/loaded. This is the closing bracket to file PRECOMPILE.
- This is a large chunk of the Lisp 2 compiler.
- This is more of the Lisp 2 compiler.
- This is more of the Lisp 2 compiler. This file contains the infamous EXHOCKY function. The recursive interior compiler function produced state of compilation information and individual compiler parts would use that information to minimize code output. One of the implementers, Bob Saunders, knew more about the ANFS Q32 (the Lisp 2 host) than just about anybody. He got tired of middle-of-the-night calls asking him how to do various state resolution tasks. His phone number, in the 213 area, was EXHOCKY. So he wrote a function for our code to call instead of waking him up.
- The implementation of a miniature similarity predicate.
- The system top-level including EVAL and EVALQUOTE.
- An extremely limited compiler. (It was probably used to compile pieces of LISP input at a command prompt or for presets to top-level variables.)
- Another extremely limited compiler. A guess from its name: used to compile the highly stylized output of the META meta-compiler.
Notes on Lisp 2 development
During the Lisp 2 project, several researchers were loaned to the project and paid by their employer. Two important examples were Warren Teitelman (BBN) and Fred Blair (IBM Watson Research). Warren made available a technology based on FLIP, a pattern-driven data manipulator. When the input matched a pattern, pieces of the input were combined to produce the output. Fred was one of the co-inventors of Scratchpad, an early example of a computer algebra system. Some work was done making Scratchpad-like capability available for Lisp 2.
Erwin Book and Val Schorre developed meta-compiler technology, first as part of an early 1960’s UCLA ACM SIGPLAN working group, then as a full-time professional endeavor at SDC. That meta-compiler was used to generate various frontends to Lisp 2 and was itself (if memory is accurate) coded in Lisp 2 and available to Lisp 2 application programmers.The Lisp 2 code developed for the FLIP, Scratchpad, and META contributions is not included in the above listing.