Source-to-Source Code Generation Based on Pattern Matching and Dynamic Programming

Transcription

1 Source-to-Source Code Generation Based on Pattern Matching and Dynamic Programming Weimin Chen, Volker Turau TR August, 1993 Abstract This aer introduces a new technique for source-to-source code generation based on attern matching and dynamic rogramming. This technique can be alied to all source and target languages which satisfy some requirements. The main differences to conventional aroaches are the comlexity of the target language, the handling of side effects caused by function calls and the introduction of temoraries. Code otimization is achieved by introducing a new cost-model. The technique allows an incremental develoment based on imrovements of the target-library. These require only a modification of the rewriting rules since those are searated from the attern matching algorithm. Exerience of an successful alication of our technique is given. GMD-IPSI, Integrated Publication and Information Systems Institute, Dolivostr. 15, Darmstadt, Germany. chen@darmstadt.gmd.de On leave from: Fachhochschule Giessen-Friedberg, Fachbereich MND, Wilhelm-Leuschner-Str. 13, Friedberg, Germany. turau@rfhfb.fh-friedberg.de

2 1 1. Introduction In this aer a new technique for generating otimized code for object-oriented rogramming languages based on attern matching and dynamic rogramming is resented. It can be alied to translation on a source to source basis. Pattern matching and dynamic rogramming have been alied before in comilers based on the back-end aroach, i.e. where the target code of the comiler consists of hardware-oriented instructions. However, when alying this technique to target languages which are high level rogramming languages, several essential differences need to be overcome: the target language is far more comlex than machine code, the evaluation order can not be guaranteed by a simle traversal strategy for the syntax tree, since function calls may cause side effects, temoral variables must be introduced, and a new cost model for code otimizing is needed. Our technique is based on a set of rewriting rules, which allow us to handle functions with a variable number of arguments as well as temoral variables. A roof is given, that the evaluation order in the generated code is consistent with that of the source code. The code generation starts from the syntax tree and is done in the following way. All temlates in the tree rewriting rules are matched against the subtrees of the syntax tree during a deth first traversal of the tree. At each node, the costs are used to determine the best match and, the selected subtree is relaced by the associated relacement node. The dynamic rogramming algorithm allows the rules to be written in any order and obviates the need to deal with attern matching conflicts. It roduces code that is otimal with resect to the cost rovided. Comilers based on the front-end aroach are used to save the big effort to generate machine code instead the translation is into another rogramming language for which a comiler exists [4, 15]. This aroach is very useful for comilers of new languages, because it allows a flexible and extensible imlementation. Furthermore, it is latform indeendent. The general situation is deicted in figure 1. The frontend comiler erforms syntax and semantic analysis. Then the hase of code generation starts. The outut of this hase is a semantically equivalent rogram in the target language which contains calls to function, which are rovided by a target library. The target comiler utilizes this library to generate executable code. The introduced technique can be alied to all source and target languages which satisfy some requirements. The roblems which arise when this techniques are alied in the front-end aroach are dicussed and are of indeendent interest. The remainder of this aer is organized as follows. Section 2 states the background for the source- and targetlanguages and details the translation rules. Section 3 outlines the general rincile of our technique and resents the new features. Section 4 discusses the control facility in the attern matching. Section 5 reorts the exerience gained in alying the new technique. Section 6 surveys related work and section 7 concludes the aer with a discussion of our results. source syntax analysis semantic analysis code generation target code target-library target comiler Fig. 1. The module structure of the front-end comiler

3 2 2. Background In this section the requirements of the source- and targetlanguages and of the translation rules are discussed. The focus of our work is on the basic concet of object-oriented rogramming languages: the class-concet. A class defines roerties 1 and methods. Source language: The language is strongly tyed. It can be assumed that the roerties of the classes are globally identified during the hase of semantic analysis, where rename techniques are required. E.g. a roerty-reference can be written where the exression exr is an instance of a class while is a roerty of that class. In the hase of semantic analysis, the tye of exr can be statically determined so that it is ossible to globally identify all roerties of all classes. Let be the set of all globally identified roerties. The methods of a class may cause side effects changing the values of roerties in. Most object-oriented languages suort dynamic disatching. As a consequence, in general it is not ossible to statically bind a generic method invocation to a concrete method at comilation-time. For a strongly tyed language, however, it must be ossible to determine the set of methods (in the corresonding classes) which may be invoked for the given (generic) method invocation. At comile-time, we can globally identify the methods of all classes, and define the set of these methods as. For every m let (m) be the set of those roerties which may be effected by the method m. Let D (m) be the disatchingset of those methods which may be disatched for a given method invocation m. We denote * ={{m} m } { D (m) m }. The set * 2 can be constructed at comilation-time. Thus, for each (generic) method invocation m, we can always find the unique corresonding element m * * at comilation-time, deending on the context that method m is stated as dynamic disatched or not. Therefore, for each (generic) method invocation m, let * (m) be the set of those roerties which may be effected by an invocation of m: 1. Different languages have different concets, e.g. in C++ it is called member attribute, in Smalltalk it is called instance variable. * (m) = mm * (m) where m * * corresonds to m. In the following discussion, a method invocation is written as m(arg 0,..., arg n ) 2, where m is globally identified and * (m) is already constructed at comilation-time. The body of each method m may define local variables, which are available in the method body only. Let (m) denote the set of these local variables defined in method m. In contexts that do not lead to ambiguity, we denote this set as. Target language: The language suorts the mechanism of function invocation. Functions are allowed to have a variable number of arguments. The language suorts function olymorhism. Therefore, for a source exression we can ignore the tyes of the oerands when alying attern matching to code generation. E.g. the olymorhic function VOID writepro(string, OB- JECTS, TYPE), where TYPE can be any target tye, reresents writing the v 0 by writepro(,v,v 0 ), regardless of what tye of v 0 is. The language suorts tye casting. Translation rules: All source data tyes of the same kind are maed into the same target data tye. Hence, only a fixed set of target data tyes is defined in the target language. For examle, all source class-tyes are maed into a single target tye: OBJECTS. All source array-tyes are maed into a single target tye: ARRAY. Each rimitive source tye is maed into an individual target tye, e.g. INTEGER is maed into INT. The body of each method is translated into a corresonding function. There exists a set of functions of the target language which reresent the basic statements/exressions of the source language. These are rovided in the interface of the target-library shown in Fig Some languages, e.g. C++, write a method call as o.m(arg 1,..., arg n ). By syntax transformation, it is ossible to write that as m(o, arg 1,..., arg n ).

4 3 All roerty accesses are translated into function calls in which the roerties are assed as identifierreference arguments. The above function write- Pro is an examle. Another examle is the function VOID readpro(string, OBJECTS) which reresents reading the source by (TYPE)readPro(,v). where the word TYPE is the name of the target tye of the and is needed for tye casting. The unit of the translation is a statement. Each statement is translated into one or more target statements. It is not the intention of this aer to cover all object-oriented aradigms. Rather the focus is on source-to-source translation at the statement/exression level. In the following, the source/target code is reresented by Helvetian/courier font resectively. Letters, v, and m to denote the elements of,, resectively. 3. Princile of attern matching In the conventional aroaches for code generation which are based on attern matching, the machine descrition is searated from the code generation algorithm. They emloy a formal machine descrition and use a code-generator-generator to automatically code generators. In this scheme, attern matching is used to relace interretation with case analysis. Rewriting rules may be tree-structured [3] or linear [7]. Corresondingly, attern matching is erformed by heuristic search or arsing Rewriting rules A attern matching system R is a finite set of rewriting rules, each of the form l r, where l and r are terms built from the set of labelled symbols and a set of atterns. We use tree structures to reresent the atterns. To illustrate this idea, consider an examle. Source 1 Syntax tree: ro Rewriting rule: R 1 : v ro v (ro tt)readpro(,v 1 ) v 1 Pattern matching: (where ro tt denotes the target tye (tt) at node ro) v R 1 ro Target code: v (TYPE)readPro(,v 2 )) where TYPE denotes the value of ro tt. In this examle, suose that the variable v 1 in the target code has been declared corresonding to the source variable v 1, in an aroriate maing. Consider another examle. Suose the olymorhic function TYPE sum(type,...), where TYPE is an aroriate target tye, reresents the source exression v 1 +v v n by sum(v 1,v 2,...,v n ) for any n > 1. This code can be matched by the following atterns: R 2 : R 3 : R 4 : v 1 1 lus v 2 v sum( 1, 2 ) lus 1, 2 2 v In the above rules, denotes a nonterminal symbol while the code of consist of arguments for a function call. E.g. given an exression v 1 +v 2 +v 3, the syntax tree is lus lus V3 V2. The matching rocedure can be R 4 lus R 3 R 2 V lus R 4 V2 R 4 V3 so that the target code is v sum(v 1,v 2,v 3 ). (1) Note that the matching strategy is not unique. Another matching rocedure can be R 4 lus R 4 V2 R 2 V R 2 R 3 V so that the target code is lus R 4 V3

5 4 v sum(sum(v 1,v 2 ),v 3 ). (2) As a reliminary estimation, code (1) is better than code (2), since in (1) only one function invocation is required. As another examle consider an array with multile dimensions. Suose a target function VOID arr(array,int,...) reresents reading a source exression v 0 [v 1 ][v 2 ]...[v n ] by (TYPE)arr(v 0,v 1,...,v n ) where TYPE is the target tye of the source exression. The corresonding rewriting rules are defined as follows: R 5 : v arr v (arr tt)arr(,v 1 ) R 6 : v 1 arr 1,v 1 v R 7 : v v E.g. given an exression v 0 [v 1 ][v 2 ], the syntax tree is arr arr v 2 v 0 v 1 The matching rocedure can be R 5 arr v R arr 6 v 2 R v 7 0 v 1 and the corresonding code is v (TYPE)arr(v 0,v 1,v 2 ). Again there are several different matching rocedures, e.g. another matching will generate the code v (TYPE)arr((ARRAY)arr(v 0,v 1 ),v 2 ) Costs of rules (3) In the conventional aroach, each rewriting rule has a designated cost, so that the otimization degree for the target code can be measured by the total cost of rules matched. In the conventional aroach, the target code of each rewriting rule consists of hardware-oriented instructions. It is relatively easy to designate a cost to a rule, because the instructions are relatively simle. However, in our frontend aroach where the target code is comosed of a series of function calls, the cost of a rule relies on how the target functions are imlemented. Generally seaking, the cost of a rule can be estimated either by analyzing the function imlementation, or by counting u the average execution time corresonding to the individual function calls. In some situations, the cost of a general function call deends not only on the function imlementation itself, but also on what the actual arguments are. For examle, suose function union(set 1,SET 2 ) is the target code for a source exressions that builds the union of two sets. Thus, the cost of the function union will dynamically deend on the sace-comlexity of the arguments. Unfortunately, analyzing this sace comlexity at the comilation-time is a difficult task and in some cases imossible. This fact leads to an aroach where each function call gets assigned an estimated average cost regardless of the dynamic sace comlexity of the arguments. There are two kinds of target functions: functions with a fixed arity, and functions with a variable arity. In the first case, the cost of a function call is a fixed nonnegative value; in the second case, the cost of a function call deends linearly on the number of the arguments. For instance, consider the function sum where a variable number of arguments is allowed. The cost of this function call can be calculated by the following formula: cost(sum(arg 1, arg 2,..., arg n )) = c 0 + n c a where c 0 is the cost in the case no arguments are resent, and c a is the incremental cost for each new aended argument. This linear model is motivated by the following fact: in the body of a function, a loo is always used in order to access iteratively the arguments aearing in the function call. Normally, the number this loo is executed linearly deends on the number of the arguments. Meanwhile, the cost of the function call will linearly deend on the number of these runs. For the exression v 1 +v 2 +v 3 two different target codes were generated. By the above model, the costs of alternatives (1) and (2) are c 0 + 3c a and 2c 0 + 3c a, resectively. Therefore, as we have stated, alternative (1) is better than (2). According to this model, the costs of rules R 2, R 3, and R 4 must be designated as c 0, 0, and c a, resectively. The discussion above shows that a target function call may be generated by matching a sequence of rewriting rules. Therefore, the cost of a function call is equal to the sum of the costs of the corresonding rules. In order to simlify the cost model, the set of rewriting rules is restricted in a way that only the root can have variable arity. In general, the cost of a rule is a nonnegative val-

6 5 ue, which may deend on the arity of the root of the treeattern, if the root has variable arity Evaluation order In a syntax tree, the evaluation order among its nodes is always fixed, e.g. left-right or right-left. On the other hand, the evaluation order in the target code is also fixed. It is necessary to ensure that both evaluation orders are conformable. We denote the set of rewriting rules by. Let oerand 1 and oerand 2 be two arbitrary different oerands of the syntax tree. Let arg 1 and arg 2 be the corresonding oerands of the target code. Now two kinds of orders are considered. One is the evaluation order between oerand 1 and oerand 2 in the syntax tree. The other one is the evaluation order between arg 1 and arg 2 in the target code. We say, is consistent, if these orders are conformable for all airs of oerands. In the context of this aer, we assume that the evaluation order in the syntax tree is right-left and in the target code the arguments of a function call are also evaluated in right-left order. A sufficient criteria to ensure that the set of atterns is consistent is that if an oerand aears on the right-hand side of another one then the code corresonding to the first oerand must aear on the right-hand side of the code corresonding to the second one. It is clear that a non-consistent set of rewriting rules or illegal traversal order of the syntax tree can result in a target code with an illegal evaluation order. However, the correct traversal order of the syntax tree as well a consistent set of rewriting rules are still insufficient to ensure the correct evaluation order in the target code by any attern matching. The roblem is the following. A method m may cause side effects modifying some roerties in * (m). If a statement or exression contains m as well as some roerties of (m), then the evaluation order between m and the roerties in * (m) must be conformable between the source- and the target-code. This will be illustrated by an examle. On the one hand, the target code of m can be matched by the following rules: R 8 : v mc v m() m R 9 : v mc-dth v disatch( m,) m R 10 : ex-list * v v * R 8 and R 9 describe the rules for method calls in the context of static binding and dynamic disatching. In R 10, the iteration notion * indicates that the arity of node ex-list is variable and 0. Corresondingly, the code of consists of the concatenation of the code son s code. Later this will form the arguments of a function call. Therefore, given an exression m(v 1 )[@v 2 ], the syntax tree is arr mc m ex-list v 1 ro V2 Matched by rules R 1, R 5, R 7, R 8, and R 10, the target code is v (TYPE)arr(m(v 1 ),readpro(,v 2 )). (5) Consider the case that the following new rule R 11 : v arr v arr(v 1,,v 2 ) v 1 ro V2 is introduced in order to translate the source exression v 1 [@v 2 ] into v (TYPE)arr(v 1,,v 2 ) Here the roerty is dereferenced in the function body arr but the value of v 1 is evaluated in the argument art, i.e. is evaluated after v 1. In this case the evaluation order is not sensitive, so that the code is still correct. However, if the tree (4) is matched by the rules R 8, R 10 and R 11, then the target code becomes v (TYPE)arr(m(v 1 ), 2,v 2 ). (6) In the case * (m), thus the evaluation order between the method m and the roerty is illegal. This examle illustrates that the roblem of illegal evaluation order does not result from the traversal strategy for the syntax tree, but does result from the control in attern matching. In this source-to-source background, the issue of evaluation order comes from method calls which may cause side effects. Besides this case, the evaluation order is not sensitive where the code generator may evaluate exressions in an order that reduces the cost of evaluation. (4)

7 Temoral variables So far we merely considered the rewriting rules which are used to read exressions. However, for rules involving reading and writing of variables or roerties a roblem arises. Consider the source statement v 1.:=v 3 with the following syntax tree ro assign v 2 v 1 (7) As we assumed in section 2, the target code must be writepro(,v 1,v 2 ). However, if rule R 1 is chosen to match the shadowed art as follows R ro 1 v v1 assign v 2 the target code would be wrong, since the code of R 1 just returns the value of v 1. and does not erform the actual udate. Consequently, the target code only changes the (hidden) temorary v but v Control in attern matching Several tree-attern matching algorithms have been resented. For code generation alications, a scheme roosed by Hoffman and O Donnell [13] aears romising, and it is successfully alied in the system Twig for code generator-generators by Aho, Ganaathi, and Tjiang [3]. They suggested that temlate matching can be done efficiently by extending the Aho-Corasick multile-keyword attermatching algorithm [1] into a to-down tree-attern matching algorithm. Afterwards, alying the bottom-u heuristic search, the cheaest tree-attern matching can be found. This algorithm can be extended to our alication. In this aer we do not intend to discuss the details of the algorithm. Instead, we state some key roblems which occur in our alication, but do not occur in the conventional aroaches and resent our solutions Controlling the evaluation order Controlling the evaluation order can be divided into two categories. One is the order between methods and methods. Another one is the order between methods and roerties. Without loss of generality, in this section we can assume that the method call is always in the context of static binding. From the view of controlling the evaluation order, a method call in the context of static binding or dynamic disatching does not make an essential difference. In the syntax tree, we introduce the notion nm if node m is an ancestor of node n, and the notion nm if n=m or nm. We have the following results. THEOREM 1. Suose the set of rewriting rules is consistent and that only rules R 8 and R 9 contain nodes for method calls. Then for any attern matching the evaluation order between methods and methods is always correct. PROOF: Let m 1, m 2 and mc 1 and mc 2 their corresonding nodes in the subject tree c. Let the traversal of the subject tree be the bottom-u and the right to left order. Suose node mc 1 aears before node mc 2. Now we rove that, by any attern matching, the code of m 1 is always evaluated before m 2. Clearly in the case that mc 1 mc 2 the code for m 1 is embedded in the argument of a function call which is the code for node m 2. Hence, the code for m 1 is evaluated before that for m 2. Note that the case mc 1 mc 2 can not occur. Consider the remaining case of mc 1mc 2. Suose node n is the first common ancestor of nodes mc 1 and mc 2. By any matching, there always exists a node n f (n f n) such that at n f there is a function call f generated. According to the assumtion that only the rules R 8 and R 9 contain nodes for method calls, the code of m 1 and m 2 must be embedded in two different arguments, arg i and arg j. Moreover, arg i and arg j are not identifier-references (c.f. the definition of rule R 8 ). Suose the code arg i and arg j are generated at nodes n i and n j resectively. Hence, the relation nn i mc 1 and nn j mc 2 holds, while n i must be on the right-hand side of n j since mc 1 is on the right-hand side of mc 2. mc 2 n j n f m 2 m 1 n n i mc 1 Therefore, in the function call f, argument arg i must be on the right-hand side of argument arg j so that all code in arg i is evaluated before code in arg j, hence the code of m 1 is evaluated before m 2.

8 7 Before discussing how to control the evaluation order between methods and roerties, we introduce some notations. For each node n in the syntax tree let (n) be the set of those methods which occur in the subtree rooted at node n. Moreover, at node n, let * (n) be the set of those roerties which may be effected by the methods in (n), i.e. * (n) = m(n) * (m). At node n, denote the target code associated with label l as code(l, n). Here we can regard code(l, n) as a form of some arguments 3. Let * code(l, n) be the set of those roerties which occur as identifier-references arguments in code(l, n). For examle if code(l, n) is 1,f(v, 2 ), 3 then * code(l, n) = { 1, 3 }. Note that 2 does not belong to * code(l, n) because f(v, 2 ) is an argument and but 2 is not. THEOREM 2. Suose the set of rewriting rules is consistent and that only rules R 8 and R 9 contain nodes for method calls. Given a syntax tree, suose is matched by a set M = {[R i, n i ]} where the root of rewriting rule R i matches at node n i in. Assume that label l j is the j th leaf (counted in i left-right order) of R i and matches at node n j in. The target code generated by M has a correct evaluation order be- i tween methods and roerties iff the following condition holds: * (n k i ) * code(l j i, nj i ) =, for all i, j and k such that k < j. PROOF: In the syntax tree, let, m and let mc be the corresonding mc-node. Assume that the code of m and the code of are involved in a (nested) function call. It is easy to verify, that the code of occurs on the right hand side of m iff node aears before the node mc during the traversal of the subject tree in the bottom-u and the right-left order. Sufficiency: According to the restriction that in the set of rewriting rules only rules R 8 and R 9 contain nodes for method calls, if the code of occurs on the left-hand side of m, then their evaluation order is always correct, since is always evaluated after m. Now assume that the code of occurs on the right-hand side of m and * (m), while in the 3. In the case that the code is a function call, we can regard the whole function call as an argument target code the content of is evaluated after m. This means that there is a function call in the form of f(...,code m,...,,...), where code m acts as an argument of f and directly or indirectly includes the code of m. Therefore, there must be a match like the following: m n k i mc n f... n i match n j i ro l k i R i : where the function call f is generated at node n f and k < j. Now * (m) * ( n k) and i * code(l j, i nj ). This leads to a i contradiction since * (n k) i * code(l j, i nj). i... Necessity: Assume that there is a match as above such that * (n k) i * code(l j, i nj ), i.e. there exists a in the i subtree rooted at node n j (so that * i code(l j, i nj )) and a i node mc in the subtree rooted at node n k i (such that * (m) * ( n k i )). By this match, there is a function call of the form f(...,code m,...,,...) generated. Similar to the first art of the roof, the code code m acts as an argument of f and directly or indirectly includes the code of m. Consequently, in the function call f, m is evaluated before. This leads to a illegal evaluation order between m and which is a contradiction. In an algorithm, (n) can be calculated recursively in a bottom-u order for each node n in the syntax tree. It is indeendent of any attern matching. On the other hand, the value of * code(l, n) must be ket at node n associated with the label l during attern matching. In the conventional aroaches, the bottom-u heuristic search is alied, where at each node n associated with the relevant label l only the cheaest match of all rewriting rules l r is stored [3, 13]. In our algorithm, however, at each node n associated with the relevant label l, different matches that can generate different * code(l, n) must be stored (due to theorem 2). As a consequence, our algorithm for attern matching will use more sace than the conventional one. l j i

9 Handling of temoral variables One way of handling udates for temoral variables is to aly the attern matching only to certain subtrees of the syntax tree. Given a source statement which modifies an object, the ath from the node corresonding to the modified object to the node corresonding to the modifying oeration 4 is called writing-ath. If a syntax tree includes a writing-ath, then attern matching is only alied to those subtrees which do not include nodes of the writing-ath. In other words, for the subtree which includes nodes of the writing-ath, code generation must be erformed by traditional case analysis, since the current matching strategies are not suited for syntax trees containing writing-aths. Informally seaking, given a syntax tree which includes a writing-ath, attern matching is alied to the subtrees obtained after deleting the nodes of the writing-ath as well as the edges leading to those nodes. For examle, in the tree (7), the bold ath is the writing ath so that attern matching is only alied to the subtrees and v 2 (they are already nodes). For a more illustrative examle consider the statement, v 1 [v 0 +v 2 ] := v 1 [v 0 ]. The syntax tree is assign arr (t lus 2 ) v 0 V2 arr (t 1 ) where the bold ath is the writing-ath. Thus, attern matching is alied to the shadowed subtrees (t 1 ) and (t 2 ). Afterwards, the syntax tree becomes arr assign v tm2 v tm1 which must be treated by traditional case analysis. 4. We do not regard that the node of method call mc is a modified oeration, although certain method calls can cause side effect. v 0 5. Exerience We imlemented this front-end aroach successfully to translate the schema language VML into C++ [5]. The general issues of the VML comiler are described in [16]. VML is the modelling language of the object-oriented database system VODAK develoed at GMD-IPSI. The target language C++ satisfies the requirements stated in section 2. In fact, from the oint of view of comilation at statement level, we did not rely on other object-oriented features of C++. By this exerience several notes can be concluded as follows. First, assigning costs to rewriting rules is a difficult task and may undergo several revisions in order to reflect the changes during the system maintenance. When introducing new rewriting rules, the following assumtion must be obeyed: ASSUMPTION 1. The semantics of rewriting rules does not rely on the costs of the rules. Secondly, we assumed that the arguments of a target function call are evaluated in right-to-left order. However, if the arguments consist of more than one identifier-reference (E.g. we can define a olymorhic function call sumpro( 1,v 1,..., n,v n ) to reresent a source exression n, for any n > 0.), then the evaluation order among these arguments will rely on the function imlementation. For instance, in the function sumpro the values of 1 to n must be evaluated in right-to-left order. Nevertheless, this requirement somehow can lead to an imlementation in a zigzag way. E.g. in the body of function sumpro, the arguments should be counted in left-to-right order, because a variable number of arguments is allowed. Thus, it is necessary to introduce a stack in order to ush all arguments, and latter to o them in the reverse order for the urose of dereferencing these identifier-reference arguments. Clearly this way more sace would be required comared to the more direct way of dereferencing these arguments as soon as they are encountered. Fortunately, the correctness of theorem 1 and 2 does not rely on this restriction. ASSUMPTION 2. The bodies of target functions do not rely on the order in which their identifier-reference arguments are evaluated. Third, as mentioned above, attern matching only needs to control the evaluation order either between methods and methods or between methods and roerties. If a rewriting rule secifies more than one method call or a mix-

10 9 ture of method calls and roerties, then attern matching would be owerless to control the dereferencing order among these method-calls and/or roerties, since the control is already transferred to the body of target functions. As a consequence of assumtion 2, this case would not be under control. Therefore, there is a necessity to restrict the atterns to searate method calls from other kinds of nodes. ASSUMPTION 3. The set of rewriting rules must be consistent, such that only rules R 8 and R 9 contain nodes for method calls. 6. Comarison with revious work Previous research in attern-directed code generation can be broadly classified into two categories: LR arsing and tree-attern matching. With the former one, the code generator is constructed as a syntax-directed translator in which a linearized refix form of the IR tree is arsed by an LR arser built from a context-free grammar that describes the target machine [7, 8, 10-12]. With the later one, the aroach emloyed direct tree-attern matching techniques [1-3, 6, 13]. But all of them are focusing on source-to-machinecode translation. On the other hand, the current aroach for source-tosource code generation is still the traditional case analysis. This has been very useful for many alications. In general, the algorithm for case analysis is distributively defined at each node in the tree, and refers to the synthesized and inherited attributes. In the source-to-source background, one target instruction may cover a variable deth of the tree while there may be different alternatives to be chosen for the same tree. It is necessary for case analysis to consider the different combinations from the current node to its children and/or arent, and even to deeer levels. By far the largest roblem of this aroach is that the definitions of the target instructions are difficult to modify, since the algorithm for case analysis must follow this modification also. Benefited from the theoretical and ractical work that has been done on the conventional dynamic rogramming, this aer extends the tree attern matching into source-tosource code generation. However, there are several differences. The main oint is that the attern matching algorithm must exlicitly control the evaluation order. In our source-to-source background, instructions are function calls in which roerties are assed as identifier-reference arguments. As a result, the dereferencing order may violate the semantic. In conventional aroaches, however, the issue of evaluation order is not resolved in the hase of attern matching. It is assumed that the evaluation order is correct rovided a traversal strategy for the syntax tree secifies a legal order [14], since the syntax tree must be rewritten into machine-level (intermediate reresentation) before alying the attern matching. Consequently, the rewritten tree already uniquely determines the evaluation order. Suose, for examle, the syntax tree (4) is translated into machine code. Before alying attern matching, the tree must be rewritten into a form of function calls so that choosing the machine code corresonding to code (5) or (6), which secify different evaluation orders, is actually already determined in this hase, not in attern matching. 7. Discussion & Conclusion This aer extends conventional dynamic rogramming into source-to-source code generation. Based uon this aroach, the rocedure for otimization shows good oenness. In the conventional background, target instructions are redefined by hardware and are fixed. In contrast, in our alication the target instructions are a series of function calls and can be develoed incrementally. Generally seaking, initially rimitive instructions can be defined in the target-library. Latter, secial comosite instructions can be added to imrove the efficiency, esecially frequently occurring grous of rimitive instructions can be defined as comosite instructions. Although from the oint of view of semantic comleteness, the comosite instructions are redundant, but they lay an imortant role in the otimization, since more direct reresentations lead to a higher erformance. To facilitate an incremental develoment based on the imrovements of the target-library, a modular design is needed. The dynamic rogramming aroach aims to achieve this goal. Imrovements of the target-library require only modifications of the rewriting rules since those are searated from the attern matching algorithm. Acknowledgements We thank Wolfgang Klas and Peter Muth, for reading a reliminary version of this aer and suggesting imrovements for its resentation. References 1. AHO, A. V., AND CORASICK, M. J. Efficient string matching: An aid to bibliograhic search. Comm. ACM 18,6 (June 1975),

11 10 2. AHO, A. V., AND GANAPATHI, M. Efficient string matching: An aid to code generation. In Proc. of the ACM Sym. on Princiles of Programming Languages. ACM, New York, 1985, AHO, A. V., GANAPATHI, M., AND TJIANG, S. W. K. Code Generation Using Tree Matching and Dynamic Programming. ACM Trans. Program. Lang. Syst (Oct. 1989) AGRAWAL, R., DAR, S., AND GEHANI, N. The O++ database Programming Language: Imlementation and Exerience. Proc. on Data Engerienging CHEN, W.-M., AND TURAU, V. VML Code Generatin Based on Tree-Pattern Matching and Dynamic Programming. Tech. Re. 755, 1992, GMD-IPSI. 6. FRASER, C. W. Automatic Generation of code generators. Ph.D. Dissertation, Yale University, New Haven, Conn., GLANVILLE, R. S. A Machine Indeendent Algorithm for Code Generation and Its Use In Retargetable Comilers. Ph.D. Dissertation, University of California, Berkeley, Dec GLANVILLE, R. S., AND GRAHAM, S. L. A new method for comiler code generation. In Proc. ACM Sym. on Princiles of Programming Language. ACM, New York, 1978, GORLEN, K., ORLOW, S., AND PLEXICO, P. Data Abstraction and Object-Oriented Programming in C++. John Wiley & Sons, HENRY, R. R. Graham-Glanville Code Generators, Ph.D Dissertation, Comuter Science Division, Electrical Engineering and Comuter Science, Univ. of California, Berkeley, HENRY, R. R., AND DAMRON, P. C. Performance of Table-Driven Code Generators Using Tree-Pattern Matching. Tech. Re , Det. of Comuter Science, University of Washington, Seattle. Feb HENRY, R. R. Encoding Otimal Pattern Selection in a Table-Driven Bottom-U Tree-Pattern Matcher. Tech. Re , Det. of Comuter Science, University of Washington, Seattle. Feb HOFFMAN, C. W., AND O DONNELL, M. J. Pattern Matching in Trees. J. ACM 29, 1 (1982), LANDWEHR, R., JANSOHN, H. S., AND GOOS, G. Exerience with an automatic Code Generator Generator. ACM SIGPLAN Notices 23, 7 (1982), RICHARDSON. J. E., AND CAREY. M. J. Persistence in the E Language: Issues and Imlementation. Software Practice & Exerience 19, 12(Dec. 1989), TURAU, V., AND CHEN, W.-M. VML Comiler: Issues and Imlementation. (submitted for ublication)

12