PLASMA(ID:8499/)


evolution of METAPLAN by Graham and Ingerman


Related languages
METAPLAN => PLASMA   Evolution of

References:
  • Graham, ML; ad Ingerman, PZ "A universal assembly mapping language" Proc. ACM 20th Nat. Conf., 1965, pp409-420 view details
  • Feldman, Jerome and Gries, David "Translator writing systems" p77-113 view details Abstract: A critical review of recent efforts to automate the writing of translators of programming languages is presented. The formal study of syntax and its application to translator writing are discussed in Section II. Various approaches to automating the postsyntactic (semantic) aspects of translator writing are discussed in Section III, and several related topics in Section IV. Extract: PLASMA
    PLASMA (Graham and Ingerman [GraM 65])
    The meta-assembler effort of Graham and Ingerman concentrates mainly on the problems of substitution and binding. They are much less concerned with syntax than Halpern (next discussion), because they assume a syntaxdirected front end (presumably [Ing 66]) for a compiler written in their system.
    The basic input to their meta-assembler is a "line" which is a list of lists. The first list is a generalized label consisting of a symbol, the number of higher levels at which it is active, and the number of lower levels at which it is active. The second list contains the operation, and the third contains the operands. The input is converted into a tree, and substitutions are made on the basis of the tree structure.
    By allowing substitutions by symbolic or numeric value, they combine the text replacement with assembly functions.
    The authors are continuing their work at RCA, Cherry Hill, and will presumably report on it again. Their current efforts involve even more elaborate substitution processes. They have not, as yet, put forth specific suggestions on how their system might be used as the basis for a compiler. Extract: METAPLAN
    METAPLAN (Ferguson [Fer 66])
    The article by Ferguson is taken from the ACM Programming Language Conference, San Dimas, California, 1965, and contains a good introduction to meta-assemblers. The basic ideas arose from observing that all assemblers have many features in common. By building procedures for handling such things as symbol tables, location counters and macros, one could speed up the writing of particular assemblers. To construct an assembler for a particular machine one would specify word size, number representations, and the like. Output for each machine would be programmed using format statements and could easily include relocation or symbolic debugging information. While such a system seems feasible and quite useful for writing assemblers, it is not obvious how one would extend it to a TWS.
    The use of a meta-assembler as a TWS is based on the previously mentioned assumption that the compiler is a special case of the macro assembler. Discussions of this assumption sound like a reincarnation of the macro versus high level language debate. The macro assembler side is on the defensive, is outnumbered, and therefore has been the most vehement in argument. The whole situation is further complicated by a lack of agreement on what an assembler is (cf. discussion following the paper [Fer 66]). An example will suffice for our purposes.
    Fergnson describes how a recta-assembler would handle the compiler-like statement:
    1F F(A) PLUS 5 EQ G(B) GO TO L.
    He would have IF, PLUS, EQ, and GO TO be defined as (prefix) operators using a scheme called many-many macro. The many-many macro has features for using and updating state information during text replacement. This attacks the main problem in the more general use of macros--the effective use of global properties (state information) in the assembly process. The many-many macro is probably flexible enough to implement any known compiler; the real question is whether the many-many macro is a good way of doing it. The answer to this depends on the mechanisms for recording and using state information, and these are not discussed in the paper.
          in [ACM] CACM 11(02) (February 1968) view details