Notes on SDC CRISP for IBM 370 Computers
by Jeff Barnett
The System Development Corporation (SDC) was one of the prime contractors selected by DARPA in 1970 to pursue research in speech understanding systems. Thus, SDC was a major participant in the DARPA Speech Understanding Research (SUR) program for most of the 1970’s. SDC also had a history of developing and using Lisp systems to support their research agenda. So it was no surprise that Lisp 1.5 for IBM 360 at SDC was used to support the early speech research and that a Lisp for the Raytheon 704 Computer was developed along the way. The 704 principally supported low-level signal acquisition and processing.
Speech research would stress control structures, data representation strategies, and memory management in any existing 1970’s Lisp system. This was particularly true since a major part of the research was to determine a system structure adequate to process and understand speech. Therefore, a decision was made to design and build a new Lisp-like programming language system. That language and system was to be known as CRISP, a name derived from the phrase “Crunching Lisp,” and it was to run on the IBM 370 using the VM operating system. CRISP was designed and implemented by Jeffrey A. Barnett and Doug Pintar in the 1973-1974 timeframe.
Lisp 2 was the primary intellectual ancestor of CRISP. See the Lisp 2 for the IBM 360 (SDC TM 3417) document series for many of the design decisions that influenced CRISP. However, the special nature of speech processing and the new availability of virtual memory suggested many advances beyond those anticipated by Lisp 2. Some of the unusual features in CRISP follow:
- Spaghetti stack-like control structures
- Multiple processes with variable-binding inheritance among the processes
- Ability to dynamically change which process variables were inherited from
- Multi-clause try-form to control non-local exits and organization of search.
Data Types and Structures
- Language was strongly typed
- Recursive type definitions were allowed
- Incremental compile/assemble allowed new and old definitions to coexist, temporarily, to provide type safety
- Multidimensional arrays and structs that could be embedded and repeated within each other
- Complex, real, and integer types were supported and the latter two types were managed unboxed.
Memory and Address Management
- Clean separation between address allocation/management and memory allocation/management
- Multiple data spaces of the same sort could be created
- System builders could specify different allocation and garbage collection strategies for each data space.
- The names of global objects (e.g. function, special variable, and data space names) were in a different namespace than symbols
- Global names consisted of a first and last name (symbols) as in the Common Lisp package system for symbols, but a CRISP symbol itself had no last name
- The property list for each symbol was actually a tree and the “property name” was actually a sequence of symbols
- Function and variable names were in the same namespaces (local and global) but the use of a variable or expression as an operator was resolved by using funcall/apply automatically.
- CRISP provided both infix and Polish prefix forms for all of its language levels.
The CRISP Programming Language System: an Historical Overview, a slide presentation to the Albuquerque Lisp/Scheme Group in 2009, provides an extended introduction to CRISP. These Archives also include Crisp: a Programming Language and System (SDC TN-5455/000/00), the original CRISP manual where many details of the design and implementation are available.
One should be aware that the entire CRISP system was implemented and used to build many speech understanding and other systems. However, the CRISP language was never implemented. Since the entire intent of CRISP was to support speech research, time and funding were limited, and Doug and Jeff needed some sleep, an unusual decision was made: Implement the world's sexiest assembler. All of the interesting control structures, data types and structures, incremental compile/assemble, memory and address management, and namespaces were delivered through assembler pseudo-operations and pseudo-addresses plus a top-level declaration language and integrated libraries. For examples of CRISP code and more information about this move see The CRISP Programming Language System: an Historical Overview.