145 6 Chapter 6 An implementation Previous chapters exhibited a novel approach in incremental attribute evaluation, namely memoized visit-functions. It was rst devised by Vogt, Swierstra and Kuip er [VSK91] to solve the problems of incremental evaluation of higher-order at- tribute grammars. Vogt conducted the rst implementation exp eriments [Vog93]. This thesis continues the work of Vogt. The current chapter describ es the project of implementing a generator for attribute grammar evaluators based on memoized visit-functions. It discusses the architecture of the generator and the generated evaluators and includes some test results. Furthermore, we present a new edit mo del. We conclude this chapter with a discussion of op en problems. 6.1 Structure of the generator As part of our research on attribute grammars, we have written a generator for attribute grammar evaluators, the lrc pro cessor. The lrc pro cessor consists of a front-end which pro cesses a grammar sp eci cation into intermediate co de and a back-end which translates intermediate co de to executable co de. We have also written a to ol, that generates pro duction and plan icons. 6.1.1 Front-end The front-end of the lrc pro cessor is based on the lrc kernel, written by Matthijs Kuip er for his exp eriments with parallel attribute evaluation [Kui89]. The lrc ker- nel consists of a lexical scanner, parser and attribute evaluator. It reads a grammar sp eci cation written in ssl, the Synthesizer Sp eci cation Language [RT88], and constructs a parse tree. An attribute evaluator traverses the parse tree, checking the typ es of pro ductions, attributes, equations and semantic functions while con- structing the agstore. The agstore is a collection of data structures representing the attribute grammar. More sp eci cally it stores lists of pro ductions, equations, non-terminal and attributes, and o ccurrences of the latter two. These lists are cross-referenced where appropriate. 146 6. An implementation The Synthesizer Sp eci cation Language has b een chosen as source language forthe lrc pro cessor b ecause the Synthesizer Generatorisawell known evaluator generator for which many syntax based editors have been written. By cho osing such a wide-spread language, we assure ourself of many grammar sp eci cations to test the lrc pro cessor with. The initial version of the lrc kernel served as starting point for Vogts exp er- iments. Our project is also based on the kernal alb eit a newer version. We have added several mo dules that together implement a generatorfor attribute evaluators based on memoized split visit-functions. Each mo dule implements a phase of static analysis corresp onding with the algorithms discussed in the previous chapters. Phase 0 As an initialization, referred to as phase zero, the lrc kernel is activated to read an ssl sp eci cation and construct the corresp onding agstore. Phase 1 Phase 1 constructs the visit-sequences. We have implemented b oth algorithms, Kastens' ordered scheduling as well as chained scheduling. For comparison, gen- eralizations of Vogts greedy and just-in-time scheduling [Vog93] have also been implemented. The rst phase includes an algorithm to strip lo cal dead-ends di- verging computations from the visit-sequences. Phase 2 The second phase rst determines the life-time of attribute and binding oc- currences. Furthermore, the bind grammar is induced and the empty parcels are determined. Phase 3 The third phase of the generator induces the split grammar and the asso ci- ated encapsulators. A rst attempt to elimination has been made, but the other optimizations discussed in Section 4.3 have not yet b een implemented. Each of the four phases of the front-end generates intermediate co de as well as internal tables for diagnostics and debugging. Phase zero generates intermediate co de for equations, semantic functions and the constructors of the abstract syntax tree. Phase one generates the visit-sequences, and phase two the augmented visit- sequences and the bindings. The third phase generates the split grammar and the encapsulators. For an overview, see the following table. phase intermediate co de 0 abstract syntax, equations, semantic functions 1 visit-sequences 2 bindings, visit-functions 3 split syntax, encapsulators 6.1.2 Back-end The back-end of the lrc pro cessor reads the intermediate co de and data gen- erated by the front-end. It generates an attribute evaluator. Three orthogonal characteristics determine the kind of evaluator: the architecture visit-sequences, VSS visit-functions, FUN visit-functions, SPLIT visit-functions, the mo del plain or incremental evaluation and the target language pascal or c. Di erent architectures require di erent parts of the intermediate co de. Astan- dard visit-sequence evaluator may be generated, requiring only the intermediate 6.1. Structure of the generator 147 co de of phases zero and one. Alternatively, the intermediate co de of phase zero and one may b e mapp ed to visit-functions using the VSS mapping. In that case, no bindings are generated since attribute instances are stored in the abstract syntax tree. Thirdly, pure visit-functions FUN mapping may b e generated using the in- termediate co de from phase twoaswell. The back-end has not yet b een extended to generate an evaluator using split visit-functions SPLIT mapping. Not every architecture can b e combined with every target language or evalua- tion mo del. The following table lists valid v combinations. architecture language and mo del pascal c plain incr. plain incr. visit-sequences v visit-functions from VSS v v visit-functions from FUN v v visit-functions from SPLIT pascal is supp orted as target language for plain visit-sequence based evalua- tors b ecause part of the lrc kernel|which is written in pascal|is generated by the lrc pro cessor itself; lrc is partly b o otstrapp ed. c is chosen as main target language since it is more or less hardware platform indep endent. We have not taken the trouble to write a run-time library for every combination in the ab ove table. This explains for the missing vs. Unfortunately, this prevents us from comparing architectures, most notably incremental evaluation with visit-sequences versus incremental evaluation with memoized visit-functions. 6.1.3 Rundraw Plan icons provide for an excellent overview of the attribute dep endencies in a pro duction. We have written atool called rundraw that reads lrc output and writes a postscript le containing the pro duction or plan icons of requested pro ductions. The postscript le conforms to a sp ecial syntax so that it maybe edited by an interactive drawing program. The use of rundraw is twofold. Grammar writers sometimes use grammar The icons generated by rundraw are in constructions that take the grammar out of the class of ordered or dat grammars: essence the same as a cycle emerges in one of the tdp or dat graphs. Such cycles are much more easily the ones app earing in studied in a graphical representation. this thesis. However, they are not of presen- rundraw proved also useful while trying out new techniques. Esp ecially in the tation quality, b ecause cause of writing new scheduling algorithms with di erent priority schemes such rundraw is rather as chained scheduling or optimizations such as elimination, plan icons provide rigid in laying out quick insight in the obtained results. arrows. 148 6. An implementation 6.2 Structure of generated evaluators In this section we will describ e the structure of a generated evaluator using an incremental mo del, c as target language and an architecture based on FUN visit- functions. A generated evaluator consists of two parts: a grammar dep endent part and a xed part, the so-called library. The library can b e further sub divided into a library for plain evaluation and a library for incremental evaluation. The grammar dep endent co de is emitted by the backend. It includes co de for trees, bindings; semantic functions and equations; the visit-sub-sequences and some tables for diagnostics. The library co de for incremental evaluation imple- ments term sharing and visit-function caching. The non-incremental library co de implements terms and primitive values and the op erations on them. 6.2.1 Library for plain evaluation The majorpart of the library implements the primitive values like b o oleans, integers and strings and the op erations on them like logical and ^ , addition + and upp ercase conversion upstring . Without much trouble, additional op erations or even new primitive values can be added to the library. In addition to primitive values, the library also implements structured terms. To simplify implementation, terms are untyp ed and thus indep endent of the grammar. The library exp orts the typ e term|corresp onding to N from Section 4.4| that implements any term: ow trees, data trees as well as bindings. In a future term would also implement split trees. One would exp ect the following t version, de nition for term tag typedef termnode child struct { production_tag tag; chld1 termnode **child; chld2 struct * term; chld3 } chld4 which can be paraphrased as: \a termnode consists of apro duction tag tag and a child array rst * which holds p ointers second *to no des". We assume that The ab ove de nition is correct. However, we want to eliminate the extra sizeofint indirection from the child eld to the array of children. The idea is to \misuse" sizeofvoid*. a p ointer eld as tag eld, leading to a de nition like the following. typedef struct termnode { void * tag; struct termnode **child; } * term; 6.2.