The design of a space efficient compiler

  • Authors:
  • Michael K. Donegan

  • Affiliations:
  • -

  • Venue:
  • SIGMINI '78 Proceedings of the first SIGMINI symposium on Small systems
  • Year:
  • 1978

Quantified Score

Hi-index 0.00

Visualization

Abstract

Writing a compiler for a small machine with minimal software support can be quite difficult because the program is long and debugging aids are usually inadequate. In addition, the usual techniques for compiler writing tend to produce programs which are quite large when compared to, for example, a BASIC interpreter. This frustrates efforts for producing compilers on small machines. We describe a method which can be used to reduce the size of a compiler and simultaneously provide good debugging tools. The resulting compiler sacrifices little in terms of execution speed (in part because compilers on minicomputers are often I/O bound). We have used this method to write an MPL [1] compiler for a Microdata 32/S minicomputer. The compiler requires approximately 12K bytes of memory as opposed to 32K bytes required by the compiler produced by the manufacturer, and compiles at essentially the same speed. Appendix II outlines the syntax of the MPL language and is included to illustrate the size of the language being compiled. MPL is based on PL/I and is quite similar to the PL/M* [2] language developed by the INTEL Corporation. The method described here uses an interpretive language for writing the compiler. Thus the interpreter is the only machine language program written. We coded the interpreter in MPL and used a cross compiler to compile it, however, the interpreter could have been easily coded in assembly language. Figure 1 illustrates the savings of the interpretive language over machine code. The procedure IF_STAT is typical of a routine which might appear in a recursive descent compiler for MPL. The gain in space occurs because machine language instructions carry too much information content when applied to a special purpose (such as compiling). Note for example that a subroutine call for the Microdata requires 6 bytes, but all that is really needed is an opcode to indicate a call and a byte to indicate which of a few subroutines is to be called.