A SUIF Interface Module for Eli. W. M. Waite. University of Colorado

Size: px

Start display at page:

Download "A SUIF Interface Module for Eli. W. M. Waite. University of Colorado"

Shauna Turner
6 years ago
Views:

1 A SUIF Interace Module or Eli W. M. Waite Department o Electrical and Computer Enineerin University o Colorado William.Waite@Colorado.edu 1 What is Eli? Eli [2] is a domain-specic prorammin environment or lanuae and translator development. It embodies the standard decomposition o the translation process ound in any text on compiler construction [1,6]. An Eli user is invited to describe the characteristics o their problem in terms o this decomposition. The environment then creates C code to solve the problem described. That enerated code, which is completely independent o Eli, can be compiled by either a C or a C++ compiler and linked with other modules i desired. Most o the sub-problem descriptions are static - they describe relationships that hold amon items o inormation in various parts o a proram. For example, in most lanuaes the type o value resultin rom a dyadic operator is related to the operator indication (what the author o the proram wrote) and the types o values supplied as operands. This relationship is a static property o prorams in the iven lanuae, and can be described without statin an alorithm or operator identication [6]. Sinicant leverae can oten be ained by writin the description o a problem in a lanuae specic to that class o problem. Describin a parsin problem in terms o a context-ree rammar is a technique that has been used or many years, and one has only to look at the early literature on expression analysis [5] to et an idea o the simplication in that case. Context-ree rammars are used to describe the phrase structure o a lanuae to Eli, and reular expressions are used to describe the lexical structure o the non-literal terminal symbols appearin in that rammar. Problem-oriented lanuaes are also used to describe computations over trees, storae o entities and their properties, and production o output text. At rst lance, the use o a variety o lanuaes simply makes Eli harder to learn. The payo, however, is sinicant. For example, most o the interestin tasks o any lanuae processor involve computations over trees. A description o such a computation in a prorammin lanuae embodies relationships amon values at various nodes in the tree, a traversal alorithm, and the necessary intermediate storae. I an attribute rammar is used or the description, however, only the relationships amon values need be described - the traversal alorithm and intermediate storae requirements can be deduced rom those relationships [7]. Experience shows that hand-coded tree computations have a larer investment in the traversal alorithm and intermediate storae manaement than in the computation o the relationships. This investment is not only in the code itsel, but in the desin as well. Such alorithms are hard to et riht in the rst place, and even harder to maintain, but they are really only scaoldin or determinin the relevant values. The leverae ained rom bein able to simply inore that scaoldin is obvious. 1

2 Avoidin the need to speciy tree traversal and intermediate storae manaement not only reduces the conitive load on both implementers and readers, but supports decomposition o the specication into modules [3]. Many o the values o interest when analyzin a proram depend only slihtly on each other. For example, a compiler uses scope rules to relate uses o identiers to their denitions. That inormation allows it to determine the types o values represented by the leaves o an expression. It can then use the denitions o operators to nd what type o value is represented by every expression. The computation o expression types is quite distinct rom the computation implementin the scope rules; the ormer depends upon the result o the latter, but the detailed relationships involved are independent o one another. Not only can sets o relationships be made independent o one another, they can also be made independent o the detailed structure o the tree. Thus common computations, like the ones implementin scope rules, can be placed in libraries and reused or a variety o applications. In addition, specications or distinct subtasks can be used as buildin blocks to create a variety o processors. Eli has been in the eld or six years, and has been used to implement both special purpose lanuaes and special processors or mainstream lanuaes. The library currently contains specication modules or many o the common tree computations, and or several subtasks o processors or C and FORTRAN. For example, there are modules describin the structurin tasks or C, FORTRAN 77, FORTRAN 90 and HPF, and modules describin the symbol properties o C and FORTRAN 77. These modules have been used to implement processors that extract metrics rom C prorams, produce HTML representations o C prorams in which symbol uses reer to denitions, and convert VMS FORTRAN to RS6000 FORTRAN. Modules describin SUIF and DEC Alpha assembly lanuae are also available. The ormer has been used to produce SUIF representations o FORTRAN 77 prorams, and the latter in an experimental processor that creates symbolic debuers rom lanuae specications. 2 What does the SUIF interace module look like? The eneral orm o the SUIF interace module is a reerence manual or SUIF itsel. Eli specications are enerally written usin the \literate prorammin" style [4], which mixes descriptive text with the ormal notation to provide a document that can easily be read by humans. Our primary purpose in usin this style is to match the specication to other descriptions o what's bein specied, so that its correctness and completeness is easily determined. Three aspects o SUIF must be described by the Eli interace specication: Process control is the aspect involvin initialization o the SUIF library, creation o les in a le set, and output o each SUIF-coded procedure. Data representation provides primitives and ormation rules or describin data structure, and action representation provides primitives and ormation rules or describin control structure. The interace specication simply exports names that can be used in speciyin relationships involvin these aspects. Sinle identiers must be used to denote the types o values that are related in the tree. Because SUIF is implemented in C++, many SUIF entities are represented by pointer types denoted with leadin asterisks. The SUIF interace module uses C typede statements to provide sinle identiers or these types. These typede statements appear in sections o the specication describin the SUIF types and their purpose, and can thereore easily be checked aainst other descriptions o SUIF. Relationships amon values that are more complex than simple identity are expressed in Eli by unction application. SUIF denotes some o these relationships as method calls, which the interace module must 2

3 \packae" as unction application. In some cases, this is easily done via a #dene directive appearin in the section o the specication describin the correspondin ormation rule. In others, however, an interace procedure must be dened. Fiure 1 shows a rament o the denition as an approximation o the way it appears when printed. There are three macros shown in Fiure 1, and these are raments o the actual specication. The third o these macros illustrates use o a typede to provide a sinle identier or the proc symtab * type, while the rst and second packae the method call that creates a new procedure scope. Two specications are needed or this purpose because the packain involves both a C le and a header le. The SUIF interace module or Eli simply makes SUIF operations and data types available or use in other modules. The module is invoked by mentionin its name as one o the specications needed or a particular processor. It is up to some other module to use the operations dened by the SUIF interace module to actually produce SUIF. 3 How is the interace module used? The SUIF interace module is used by mentionin the data types and operations that it makes available in describin relations amon values at nodes in a tree describin the proram. For example, Fiure 2 shows how the interace procedures o Fiure 1 are used to create procedure scopes or FORTRAN proram units. In each case the created scope is attached to the node o the abstract syntax tree as an attribute called suiscope. This attribute can be reerred to anywhere in the body o the proram unit by INCLUDING xproramunit.suiscope, and Eli will uarantee that the value has been computed beore it is used. Thus there is no need or the user to think about how (or whether) to distribute the value to AST nodes, or when the use should be computed. Eli enerates a C++ proram rom the collection o specications it was iven. The enerated proram uses types and invokes methods that are exported by the SUIF library. Thus the list o specications made available to Eli must include the name o the SUIF library on the machine bein used. 4 Benets Eli specications are easy to create and maintain, and there is a rowin set o such specications or common lanuaes. The SUIF interace module thus simplies use o SUIF with a variety o input lanuaes, and also makes additional annotations based on special source proram analyses relatively cheap to create. Extensions o existin source can be dened readily by chanin existin specication modules, and these extensions expressed in SUIF by describin the relationships they enender amon components o a SUIF proram. Because the structure o the SUIF interace module is identical to that o the SUIF denition, it is easy to veriy that the module is correct. Also, as the SUIF denition itsel chanes, those chanes can be easily reected in the interace module. The result is that the Eli specication is much easier to maintain than an implementation written in C++. Use o an Eli specication involves no systematic loss in perormance, and in act one usually sees a ain in perormance vis{vis a hand-coded implementation durin maintenance. The reason is that chanes made in the set o relationships amon values at tree nodes oten results in a chane in the optimum traversal stratey and/or the manaement o intermediate results. With an Eli specication, the system will automatically adjust these, but the author o a hand-coded implementation usually has too 3

4 A procedure scope is created by invokin the NewProcedureScope operation, ivin the parent scope and a name describin the created scope as aruments. Normally the name iven is the name o the procedure with which the scope is associated. It is important to note that SUIF provides no connection between a procedure scope and a procedure. The user may interpret the name as a connection, but any use o that connection must be provided by user code and is not supported by the SUIF data structure. Procedure scope[8] proc_symtab * NewProcedureScope(lobal_symtab *s, char *n) { proc_symtab *t = new proc_symtab(n); s->add_child(t); return t; } proc_symtab * NewProcedureScope(ile_symtab *s, char *n) { proc_symtab *t = new proc_symtab(n); s->add_child(t); return t; } This macro is invoked in denition 53. Interace procedure prototypes[9] extern proc_symtab *NewProcedureScope(lobal_symtab *s, char *n); extern proc_symtab *NewProcedureScope(ile_symtab *s, char *n); This macro is dened in denitions 9 and 12. This macro is invoked in denition 54. The type proc symtab * must be dened as an identier to make it acceptable in an Eli specication: LIDO representations o C++ types[10] typede proc_symtab *ProcedureScope; #deine NoProcedureScope ((proc_symtab *)0) This macro is dened in denitions 7, 10, 13, 15, 23, and 27. This macro is invoked in denition 54. Fiure 1: A Specication Frament 4

5 An executable proram as a scope or symbolic names is embodied in a SuiFileSet object, while both proram units and statement unctions are embodied in SuiProcedures. The implied-do in a DATA statement is executed by the translator and thus does not appear in the SUIF proram. Each proram unit is a procedure that denes a scope. The names and types o the procedures must be derived rom context: Scope and Classes o Symbolic Names[15] SYMBOL xproramunit: suiscope: ProcedureScope; SYMBOL xproramunit SYNT.suiscope=NoProcedureScope; RULE: xproramunit ::= xlblde 'subroutine' xsubroutinename xsubproramrane xproramunit.suiscope= NewProcedureScope(GlobalScope,StrinTable(xSubroutineName.Sym)); RULE: xproramunit ::= xlblde xfunctionpreix xfunctionname xsubproramrane xproramunit.suiscope= NewProcedureScope(GlobalScope,StrinTable(xFunctionName.Sym)); RULE: xproramunit ::= xmainrane xproramunit.suiscope=newprocedurescope(globalscope,"main "); RULE: xproramunit ::= xproramstmt xmainrane xproramunit.suiscope=newprocedurescope(globalscope,"main "); This macro is dened in denitions 15 and 16. This macro is invoked in denition 19. Fiure 2: Creatin Scopes or FORTRAN Proram units 5

6 much invested in them to make any chanes. The result is that there is a steady deradation o perormance with time in a hand-coded implementation but not in the enerated processor. 5 Availability The SUIF interace module and the module that converts FORTRAN 77 to SUIF are both available with Eli 4.0. This version o the system is due or release in January, 1996 and is available or beta test by interested parties. Further inormation about Eli can be ound on the World-Wide Web at URL \ eliuser/". 6 Reerences 1. Aho, A. V., Sethi, R. & Ullman, J. D., Compilers, Addison Wesley, Readin, MA, Gray, R. W., Heurin, V. P., Levi, S. P., Sloane, A. M. & Waite, W. M., \Eli: A Complete, Flexible Compiler Construction System," Communications o the ACM 35 (February 1992), 121{ Kastens, U. & Waite, W. M., \Modularity and Reusability in Attribute Grammars," Acta Inormatica 31 (1994), 601{ Knuth, D. E., \Literate Prorammin," The Computer Journal 27 (1984), 97{ Sheridan, P. B., \The FORTRAN Arithmetic-Compiler o the IBM FORTRAN Automatic Codin System," Communications o the ACM 2 (February 1959), 9{. 6. Waite, W. M. & Carter, L. R., An Introduction to Compiler Construction, HarperCollins, New York, Waite, W. M. & Goos, G., Compiler Construction, Spriner Verla, New York, NY,

Status. We ll do code generation first... Outline

Status. We ll do code generation first... Outline Status Run-time Environments Lecture 11 We have covered the ront-end phases Lexical analysis Parsin Semantic analysis Next are the back-end phases Optimization Code eneration We ll do code eneration irst...