Compiler-Compiler(ID:179/com029)Atlas compiler generatorCompiler generator for the Atlas, with its own distinctive input language Related languages
References: in The Computer Journal 3(3) October 1960 view details in The Computer Journal 3(4) January 1961 view details in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details External link: Online copy in The Computer Journal 9(4) 1967 view details External link: Online copy in The Computer Journal 9(4) 1967 view details simulation and analyses of compiler systems (P. Bryant) The Brooker Morris Compiler Compiler system, which is a tool for easing the writing of compilers, has been exploited in the writing of a simulation compiler with the object of studying various facets of computer systems, in particular a study of the Atlas drum and disc interaction and also some multi-access problems. The compiler has also been used in a variety of industrial problems. Work is also proceeding on the evaluation of computers. This work breaks down into three main sections namely the hardware, the operating systems and the compilers and we hope that the results will provide some guide lines in determining the factors which influence a computer's performance. in The Computer Journal 9(4) 1967 view details CC (Brooker, Morris, et al. [Brook 67a, b, el) The CC (Compiler-Compiler) project started at Manchester University is one of the oldest and most isolated TWS efforts. Although the CC system has been running for some time and has been used to implement severM algebraic languages [Cou 66, Kerr 67], the published descriptions are inadequate, and the CC is not generMly understood. The CC effort has concentrated on problems of semantics; the syntax analysis is top-down with memory and one symbol look-ahead (ef. Section II.A). The result of syntax analysis is a complete syntax tree which is used by the semantic phase. This is, of course, a slow process, and there are informal provisions for other techniques. We are following the formal treatment here, taking many liberties with their notation. The input to the syntax phase is similar to BNF with the additions of "?" which can appear within angle brackets (meaning optional) and the repeat operation "." (to replace left recursion). The following statements could be used to specify the syntax of an assigmnent statement for arithmetic sums. 1. FORMAT [SS] = (variable} ~- (sum} 2. PHRASE (sum} = (sign?) {term} (terms} 3. PHRASE (term} = (variable} I (number} [ ((sum}) 4. PHRASE (terms) = (sign} (term} (terms} [ (empty) Line 1 is called a format definition and makes use of the auxiliary phrase definitions on Lines 2-4. The SS specifies the class of this format and will be discussed below. Both format and phrase definitions are used as "productions" by the top-down recognizer. The difference is that, when an intermediate tree corresponding to a format definition is completely formed, an associated format (semantic) routine is called to process it. The format routine associated with Line i would be written as follows: 5. ROUTINE [SS] .~ (variable) ~-- (sum} 6. Let (sum) = (sign?) (term) (terms) 7. ACC ~-- (sign?} (term) 8. Li: GO TO L2 UNLESS (terms) = (sign) (term) (terms) 9. ACC ~-- ACC (sign} (term) 10. GO TO L1 11. L2: STORE ACC IN (variable) 12. END Lines 5 states that this routine is associated with the format of Line 1 and will be called when the syntax has matched Line 1 and built the appropriate intermediate tree. Line 6 assigns descriptors from the intermediate tree as the values of (sign?}, (term} and (terms}. After code to load the accumulator is compiled (Line 7), the tree is examined to see if the (sum} had more than one (term}. If not, the routine compiles a store instruction (Line 11) and exits. More complicated (sum}s are treated by the loop of Lines 8, 9, 10. The actual output of code is implementation dependent and is usually done by simple string manipulation routines. There are three main classes of statements used in CC: basic (BS), master (MP), and source (SS). The BS sublanguage parallels the semantic sublanguages of FSL and TGS; it includes code generation, list processing, and lexical analysis routines in an algebraic language. These BS statements are further divided into precompiled statements (e.g. Lines 6, 8, 10, 12 above) and translator-specific compilations of BS statements (e.g. Line 7, 9, 11) defined by FORMAT [BS] statements and their associated RO UTINEs. BS statements can occur only within a format routine. Statements in the MP class inch(de the FORMAT, PHRASE, and ROUTINE statements themselves (Lines l-5) as well as editing and system dump instructions. None of these constructs can occur within a format routine. The final statements class, SS, contains the source language statements themselves. These may be interlaced with BS and MP statements making CC, in effect, a powerful extendible compiler in the sense of Section III.C. Although the CC system was originally designed to operate this way, actual practice has been somewhat different. One writes the definition of, say, FORTRAN aS ~ set of FORMAT [SS] and ROUTINE [88] statements and the CC compiles these into tables. One then records this updated copy of CC with a switch set to have CC accept only SS statements, yielding a conventional FORTRAN compiler. When used this way, CC can be modeled by Figure 12 with FORMAT and PHRASE statements as the syntax and with ROUTINEs as the semantics, linked by an intermediate tree rather than a stack. Notice that CC does not have a facility for handling descriptors for intermediate symbols as FSL and TGS do. Because CC uses a top-down recognizer, constructs are used as they are processed; this eliminates intermediate descriptors, but does force an ALGOL compiler to be written as one large ROUTINE. The CC group has recently produced reports on the uses and performance of their system. These include the first attempt to compare a TWS with hand written compilers [Brook 67b]. Brooker was able in a year to reduce the space requirement by a factor of 1.6 and the time by 1.7 by handcoding the Atlas Autocode compiler. These results are hard to interpret without more information, but they suggest that compiler-compilers need not be as extravagant in the use of space and time as many people have imagined. This is also suggested by the results of Kerr [Kerr 67]. The CC has been successfully embedded in an ALGOLlike language Atlas Autocode [Brook 67a]. An adaptation of the system called SPG (System Program Generator) is currently under development by Morris at Manchester. SPG is aimed at the systems programmer who has a knowledge of its underlying mechanisms. Implementations of the CC now exist in Atlas, the KDF-9, and the G-21, and an effort is underway at Carnegie-Mellon on the IBM 360/67. in [ACM] CACM 11(02) (February 1968) view details in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details |