SLISP(ID:6728/sli009)


Standard LISP

Fitch and Marti, Uni of Utah, 1978

Places
People:
References:
  • Fitch, J.P.; Norman, A.C.: "A Note on Compacting Garbage Collection" pp31-34 view details
          in The Computer Journal 21(1) February 1978 view details
  • Fitch, J.P.; Norman, A.C.: Implementing LISP in a High-Level Language, Software - Practice and Experience, Vol. 7 (1977), pp713-725 view details
          in The Computer Journal 21(1) February 1978 view details
  • Fitch, J.; Marti, J.: A Small Standard LISP Interpreter, University of Utah, Symbolic Computation Group, Salt Lake City, 1978 view details
          in The Computer Journal 21(1) February 1978 view details
  • Fitch, J.; Marti, J.: SLISP - A Standard LISP Implementation in SDL, University of Utah, Symbolic Computation Group, Operatin Note 37, Salt Lake City, March 1978 view details
          in The Computer Journal 21(1) February 1978 view details
  • Fitch, J.; Marti, J.: SLISP - The B-Interpreter, University of Utah, Symbolic Computation Group, Salt Lake City, 1978 view details
          in The Computer Journal 21(1) February 1978 view details
  • Fitch, J.; Padget, J. "Closurize and Concentrale" pp255-265 view details
          in [ACM SIGACT-SIGPLAN] Proceedings of the 5th ACM SIGACT-SIGPLAN symposium on Principles of programming languages 1978 , Tucson, Arizona view details
  • Marti, J. B., J. Fitch, "SLISP, A Standard LISP Implementation in a High Level Language", REDUCE Newsletter, Vol. I, No. 2, pp. 14-17, April 1978 view details
          in [ACM SIGACT-SIGPLAN] Proceedings of the 5th ACM SIGACT-SIGPLAN symposium on Principles of programming languages 1978 , Tucson, Arizona view details
  • Marti, Jed B. and Kessler, Robert R. "A medium level compiler generating microcode" pp36-41 view details Abstract: Described is a medium level language and compiler which generates microcode for the Burroughs 1800. The language significantly aids implementation of microcode interpreters for this machine.
    Extract: Introduction
    Introduction
    Students and faculty at the University of Utah have invested large amounts of energy implementing interpreters for the Burroughs 1700 - 1800 computer series. To date, these have been implemented in the Burroughs Micro Implementation Language (MIL) which has most of the inadequacies associated with order code level assemblers. The lead time between conceptualization of an interpreter and a debugged product has varied from a month to several years. The source code of these programs is usually quite illegible, adequately discouraging student experimentation and participation in projects involving interpreters.
    Implementation of experimental interpreters is not a task lightly undertaken. A number of research projects were not able to take advantage of microcoded interpreters, while others have been severely hampered by the deficiencies of the microcode assembler.
    The following are the most significant problems in working directly with microcode for the B1800.
    1. The allocation of the large number of registers with varying purposes and degrees of access is the most significant problem facing the microcoder. None of the over 50 addressable registers can be considered as truly "general purpose". Many are devoted to single function and have very restricted access. The asymmetric nature of the instruction set also forces the interpreter writer to spend an unreasonable length of time coding.
    2. MIL's primitive macro facility does not permit conditional assembly.
    3. A major source of error is that the effect of a macro may extend to registers not explicit in the macro invocation.
    4. The defined field addressing capability of the B1800 allows almost any addressing scheme. This flexibility leads to obscure code for interpreters that implement several addressing modes.
    5. Input/Output from microcode is extremely difficult. Large amounts of microcode and complicated data structures are required for communication with the MCP (Master Control Program).
    Methods of rectifying these problems have been attempted with varying degrees of success:
    1. SMACK is an I/O and debugging package which is implemented as macros for the portable macro generator STAGE2. It places most of the microcoding burden on the programmer.
    2. BIOPSI is a package of routines and macros for communicating with the MCP. A related package implementing virtual memory and paging is available as a replacement for S-memory (secondary memory) access. The packages significantly ease the burden of I/O programming in MIL, but does not provide assistance anywhere else.
    3. MMACRO is a front end macro processor for MIL which allows the user to create macros more powerful than those of SMACK or those allowed by MIL. However, the user is still faced with implementing complicated MIL macros and code.
    None of these packages is a complete solution to the problem. At best they relieve the user of the details of communication with the MCP and provide simple aids for looking at the contents of registers and storage.
    An alternative to writing microcode is to implement experimental interpreters in a high level language provided with the machine, the Burroughs Software development LANGUAGE. This approach "has proved to be prohibitive in machine time and resources. Comparisons of an interpreter for Standard LISP implemented in SDL and a similar interpreter implemented in MIL showed that the MIL version ran at worst I0 times faster, and at best over 50 times faster than the SDL version.
    A "compiler language" is the obvious choice for implementing experimental interpreters. Coding in a high level language is more likely to produce working interpreters than hand coding. High level control and data access constructs help remove the onerous burden of the MIL programming environment.
    We designed a language with features most useful for implementing interpreters for the Burroughs 1800.
    To take advantage of the high speed scratchpad registers of the B1800 there are 20 special "$ variables". References to these may be freely mixed with references to global variables resident in the S-memory. Access to these global quantities automatically produces the code necessary to move the data to and from the internal registers and secondary storage. Subscripted variables provide automatic access to indexed positions in this global secondary storage.
    Microcoded subroutines are important to the functioning of most interpreters. The compiler supports procedures in which call by value parameters are allocated to fast scratchpad registers. With the use of two internal stacks, nested and recursive calls are possible. If so specified the scratchpads may be used by a procedure without modifying their global value. Procedures may also be used as functions returning values which can be used in expressions. Secondary storage of programs and data moves randomly about reflecting the needs of the system at any given time. The code generated by our compiler performs the appropriate computations and adjustments transparently so that secondary storage appears static to the user.
    The source code of a properly structured interpreter is much easier to understand than that of one hand coded in MIL. A micro processor interpreter is only a few pages long as opposed to the 10 to 20 previously required. As the output of the compiler is MIL source language statements, hand optimization of critical sections is possible.


          in Proceedings of the 12th annual workshop on Microprogramming Hershey, Pennslyvania, United States 1979 view details