TDML(ID:7559/)

Table Declaration and Manipulation Language
References:
  • Chang. CD.. A Table-Driven Compiler Generator System, S.M. Thesis, Department of Electrical Engineering. M.I.T.. June 1966 view details
  • Marks. R.L.. A Table-Driven Syntactic Analyzer, S.M. Thesis, Department of Electrical Engineering;, M.I.T.. June 1966 view details
  • Leavenworth, B. review of Liu et al 1967 view details Abstract: The table-driven compiler building system described here should not surprise anyone experienced in compiler construction, although the system seems to be well designed and organized on a modular basis. The tasks of allocating storage and producing object code are eased by the use of a Table Declaration and Manipulation Language as well as a Macro Interpretation Language (a Syntax Defining Language is also available). No examples are given of the use of these special languages in the construction of a particular compiler, but it is fairly clear how all the parts of the system fit together and the reader is referred to other reports by the authors for further details.

          in ACM Computing Reviews 8(06) November-December 1967 view details
  • Liu, C. L.; Chang, G. D.; and Marks, R. E. "The design and implementation of a table-driven compiler system" view details
          in [AFIPS] Proceedings of the 1968 Fall Joint Computer Conference FJCC 33 view details
  • Liu, C.L. Chang, G.D. and Marks, R.E. "Design And Implementation Of A Table-Driven Compiler System" MIT-LCS-TR-042 7-1-1967 view details Abstract: Our goal is to provide users of the table-driven compiler system with an environment within which they can freely design and produce their compilers. The primary design criterion is generality so that the users can define a large class of input lang
    External link: Online copy Extract: Introduction
    The application of digital computers to diverse fields has prompted the design of many problem-oriented programming languages. Although developing a compiler for a special purpose language is no longer a mysterious task, it is still, in most cases, a tedious task that may consume many man-years. The purpose of developing a table-driven compiler system is to allow a language designer to produce and modify a compiler for his special language at a reduction of the time currently required. This facility provides a simulation environment for testing new syntactic constructions and new translation techniques for the source language, and lends itself to the more rapid development of new programming languages, especially in a time-sharing environment.
    The notion of a "table-driven compiler" is an extension of the notion of a "syntax-directed compiler" first studied by E. Irons. The difference between a conventional (i.e., not syntax-directed or table-driven compiler) and a syntax-directed compiler is that in a conventional compiler the syntax of the source language is buried in the coding of the compiler itself; the slightest deviation from the original syntax requires tampering with the original coding of the compiler - often, a hopeless task. In a syntax-directed compiler, the encoding of the syntax of the source language is kept in tables separated from the remainder of the compiler. The tables control the recognition of strings in the source language and may be readily changed so that the same processing program may handle source languages of differing syntax.
    The idea of using replaceable tables to specify the syntax of a source language to a compiler is extended in this report. In addition to tabular control of syntactic analysis, the system presented here allows the compiler designer to construct tables controlling the allocation of storage space, the method of translation, and the assembly of binary machine code. To design a compiler for a new source language, the designer need only specify these tables. To modify a compiler, he need only change the appropriate entries in the existing tables.
    The design philosophy of our "Table-driven Compiler System" is not to provide the user with an all-inclusive set of compiling facilities, but rather to provide him with an environment within which he can freely design and produce his own compiler. We wish to allow as large a class of problem-oriented input languages and object (i.e. machine) languages as possible. We try not to limit the compiler designer to specific methods for syntactic analysis or storage allocation or to specific binary machine codes.
    Extract: Markstran
    AN EXAMPLE SYNTAX DEFINING LANGUAGE
    In this section we present an example of a Syntax Defining Language, Markstran -named after its designer R. E. Marks. Markstran resembles the language described in reference 6 . The statements in Markstran define the method of syntactic analysis to be used by the Syntactic Analyzer. We first present the syntax of Markstran, and then give the Markstran program for syntactic analysis of the sample source language.
    The Markstran language has five basic statement types, Lexical declarations, Test declarations, Stack declarations, ATAB statements and TTAB statements. These statement types are translated (by the Markstran bootstrap translator) into entries in the LTAB, TTAB, STAB, and ATAB tables, respectively.
    Extract: Languages intro
    INTRODUCTION
    For the control tables to be properly filled, the designer must prepare statements in the three control languages. The statements in these languages are interpreted by the bootstrap translators and encoded into the control tables. (See Figure 2-3.) Two of the control languages, the Table Declaration and Manipulation Language and the Macro Interpretation Language, and their bootstrap translators are fixed within the system. The third control language, the Syntax Defining Language, and its bootstrap translator must be prepared by the designer.

          in [AFIPS] Proceedings of the 1968 Fall Joint Computer Conference FJCC 33 view details