TL;DR: This document is intended to be a basis for further detailing of the work completed on storage management for LISP 2 on the IBM 360, and includes brief descriptions of housekeeping information, the four phases of garbage collection, the decentralization of primitives, the organization of the pushdown stack, and the role of various data zones.
Abstract: : The document is intended to be a basis for further detailing of the work completed on storage management for LISP 2 on the IBM 360. It includes brief descriptions of housekeeping information, the four phases of garbage collection, the decentralization of primitives, the organization of the pushdown stack, and the role of various data zones. The relevance of these to the overall system is outlined, together with some of the remaining design and programming problems. (Author)
TL;DR: Many programming applications, e.g., symbolic and algebraic manipulation applications and artificial intelligence applications, require the use of list structures and none of these languages provide the user with the capability to define the cell size and/or the configuration of the list cell at runtime.
Abstract: Many programming applications, e.g., symbolic and algebraic manipulation applications and artificial intelligence applications, require the use of list structures. Several list processing languages or languages that provide for list processing have been developed, e.g. LISP 1.5, LISP 2, SLIP, PL/1, ALGOL 68, etc. With the exception of ALGOL 68 and LISP 2, none of these languages provide the user with the capability to define the cell size and/or the configuration of the list cell at runtime (PL/1 attempts to do this with BASED structures but falls short because only one component in a BASED structure can have its dimension altered at runtime). ALGOL 68 has the disadvantage that it is not yet readily available for most users, and it suffers from list tracing complexities during garbage collection. LISP 2 was an attempt to allow variable cell configurations, but the project was aborted.
TL;DR: This paper describes a computer program called UMPIRE that performs all the functions of an actual live referee for the game of Kriegsspiel and could be made operable on any computer having a LISP 1.5 compiler.
Abstract: This paper describes a computer program called UMPIRE that performs all the functions of an actual live referee for the game of Kriegsspiel. The program is written in LISP 1.5 for the System Development Corporation Q-32 Time-Sharing System. With slight modifications to the I/O functions, UMPIRE could be made operable on any computer having a LISP 1.5 compiler. The basic functions of the program are translatable into LISP 2.
TL;DR: The document describes storage allocation conventions for the LISP 2 system proposed for the IBM S/360 computer, to be partitioned into a large number of zones, each of which is classified according to the types of structural units that may occur within it.
Abstract: : The document describes storage allocation conventions for the LISP 2 system proposed for the IBM S/360 computer. Core storage is to be partitioned into a large number of zones, each of which is classified according to the types of structural units that may occur within it. The configuration of each of the standard zones and its occupant units are described in detail. A scheme for the software paging of binary program space is outlined.