Towards Automatic Partial Evaluation for the C++ Language. Robert Anisko

Transcription

1 Towards Automatic Partial Evaluation for the C++ Language Robert Anisko May 27, 2002 Partial evaluation is a high-level optimization technique that, given a program text and some of its input, generates a specialized program. It has been studied in depth for functional, imperative, logic languages, and, more recently, for object-oriented languages. Many program specializers have been developed for languages such as Scheme, C, or even Java. Yet, while many opportunities for applying partial evaluation exist in areas involving scientific computing, no tools are available for the C++ language. For a few years now, C++ programmers have used template metaprogramming techniques to achieve compile-time computations and efficient program optimizations, which turned out to be a primitive form of partial evaluation. We extend this approach with a simple program transformation system performing generation of static metaprograms from classic code. This tool is used to provide automatic partial evaluation for the C++ language. Laboratoire de Recherche et Développement de l Epita 14-16, rue Voltaire F Le Kremlin-Bicêtre cedex France Tél Fax lrde@epita.fr

2 2

3 Contents 1 Introduction 7 2 Of partial evaluation Overview Principles of partial evaluation What partial evaluation is good at Definition of partial evaluation A few properties of program specializers Compilation Compiler generation Compiler-compiler generation Online and offline specialization Decisions and specialization Online specialization Offline specialization Of template metaprogramming Overview C++ as a two-level language Compile-time computations Factorial, or a basic example Features of the static level Code generation and algorithm specialization Mixing dynamic and static code Example of compile-time optimization Drawbacks Technical issues Maintenance of static programs Automatic program transformations Motivation Generating template metaprograms Functions Variables and state Control structures Some results Factorial, again Yet another power algorithm Imperative style Benefits of this approach Limitations Further work

4 4 CONTENTS Full language support Object-oriented specialization Conclusion 31 6 Bibliography 33 A Equations 35 A.1 Functions A.2 Variables and state A.2.1 Static declarations A.2.2 Assignments to static variables A.3 Control structures A.3.1 Conditionals A.3.2 Loops

5 List of Figures 2.1 Partial application in functional programming Power Power specialized for n = Convolution benchmark with C-Mix II Online specialization Conditional with mixed binding-times Offline specialization A two-level λ-calculus Factorial with dynamic code Factorial with static code Pattern matching in static C Bindings in static C Variables in regular C Static list in C Length of a static list in C Power with dynamic code Power with partially static code Template instanciations for the power function Convolution benchmark with static programming Factorial before transformation Factorial after transformation Power before transformation Power after transformation Imperative power before transformation Imperative power after transformation

6 6 LIST OF FIGURES

7 Chapter 1 Introduction A partial evaluator, or program specializer, is a fully automatic tool, that transforms a program by specializing it with respect to some of its inputs, considered as constant, and for which concrete values are supplied, usually by the user. By using informations about these invariants, a specializer is able to perform a part of the program s computations at specialization time, thus reducing the amount of work to be done at run time by the residual program. The result is the production of a faster and more efficient application. Hence, partial evaluation is of a great interest in every field involving scientific computing, like linear algebra, computer graphics, graph theory, neural networks, image processing, and so on. While C++ is the language of choice for many developments of this kind, no native partial evaluation has ever been achieved, and no program specializer is available. In this report, we explore the relationship between partial evaluation, and the programming techniques used in the C++ community to achieve algorithm specialization at compile-time. We show that, since these techniques are a form of hand-driven partial evaluation, automatic program specialization for the C++ language can be obtained with a simple program rewriting system. This document is structured as follows. Chapter 2 is a small introduction to partial evaluation, while chapter 3 describes static metaprogramming in C++, and especially focuses on compile-time computations and algorithm specialization. Last, chapter 4 shows the link between partial evaluation and static metaprogramming, and how program transformations can be used to automate the process of partial evaluation in C++.

8 8 Introduction

9 Chapter 2 Of partial evaluation The following chapter is a basic introduction to partial evaluation. It gives an overview of what partial evaluation is, and shows a couple of general principles about program specialization, some properties with respect to compilation, and the notions of online and offline specialization. 2.1 Overview Principles of partial evaluation Given some program with several inputs, a new program can be produced by fixing some of these inputs to particular values. In functional programming, new functions can be formed by partial application (see figure 2.1). let add x y = x + y in let add 2 = add 2 in add 2 2 Figure 2.1: Partial application in functional programming Partial evaluation, or program specialization, is an automated program transformation technique that makes use of informations carried by such invariants to generate optimized programs. A classic example of partial evaluation is the specialization of the general power algorithm (see figure 2.2) to a given power (see figure 2.3). The residual programs generated by partial evaluation are considered as more efficient than the original ones, since computations on known data are performed by the specializer before program execution What partial evaluation is good at Partial evaluation, apart from its various properties in compilation 1, has many applications in every field involving scientific computing, where the main motivation for specializing programs is speed. 1 These properties are discussed in section 2.2

10 10 Of partial evaluation let power x n = if n!= 0 then x power x (n 1) else 1 in power 4 8 Figure 2.2: Power let power 4 x = x x x x in power 4 8 Figure 2.3: Power specialized for n = 4 Optimizing programs by specialization Partial evaluation can be used to significantly speedup the execution of many programs. In some cases, partial evaluation can give good results in a single run, with the execution of the specialized program plus its generation being faster than the execution of the general program... t spec (p, i 1 ) + t pi1 (i 2 ) < t p (i 1, i 2 )...as this is often the case with compilation versus interpretation: t comp (source) + t target (data) < t int (source, data) In general, partial evaluation is the most efficient when some parameters of a program seldom change. A new specialized program is then generated only when the inputs selected for specialization are modified. In such cases, the specialization time is easily amortized by many executions for a given set of invariants: t spec (p, i 1 ) + n.t pi1 (i 2 ) < n.t p (i 1, i 2 ) Last, in many applications, there are algorithms for which some input values are well-known, like convolutions and their masks in image processing. These algorithms can then be specialized in advance for these remarkable - and often used - values. Generality without sacrificing performance An additional motivation for doing partial evaluation is to gain the ability of writing very general programs, without suffering from the usual inefficiencies of highly parametrized code. Benchmark results Using an existing program specializer, C-Mix II [C-Mix], we compared the execution speed of a simple convolution program, specialized to different degrees. The size of processed images was of 512 pixels by 512 pixels, and the size of the convolution window was of 3 pixels by 3 pixels. Tests were performed with the following binding-time configurations: No specialization at all. The original program is simply executed. Specialization with respect to the size of the convolution window.

11 2.1 Overview 11 Specialization with respect to the size of the convolution window and its weights. During this benchmark, the selected weights were those of the gradient operator. Results of this benchmark are showed in figure 2.4. Figure 2.4: Convolution benchmark with C-Mix II Definition of partial evaluation A simple equational definition of partial evaluation can be given [Jones et al., 1993]. With p being the source program, i s and i d its (respectively static and dynamic) inputs, p is the residual program, and mix 2 the partial evaluator, the following property must hold: p [i s, i d ] = p is [i d ] = mix [p, i s ] [i d ] This states the obvious but essential property of a partial evaluator: applying the residual program to the dynamic input must give the same result than applying the source program to both static and dynamic inputs. In other words, the computation in two stages: p is = mix [p, i s ] out = p is [i d ] must yield the same result than the computation in one stage: out = p [i s, i d ] 2 The term being coined from the notion of mixed computation, for a partial evaluator performs both program execution and code generation.

12 12 Of partial evaluation 2.2 A few properties of program specializers Partial evaluation is, first of all, a powerful program optimization technique. Nevertheless, by some of its properties, it also has very interesting and surprising applications in compilation and program generation Compilation Let source be a program written in language S, int an interpreter for language S written in language L, and mix a partial evaluator for language L. The output of program source can be computed this way: out = source S [input] = int L [source, input] As every program with several inputs, int can be specialized, here with respect to the source program. out = mix [int, source] L [input] = target L [input] The result of specializing int for source is a program equivalent to source in language L. The specializer has been used to achieve translation from S to L. Thus, a partial evaluator can be used to compile programs without a compiler, following this equation, called the first Futamura projection [Futamura, 1971]: target = mix [int, source] (2.1) Compiler generation The same kind of reasoning can be applied to the partial evaluator himself. So far, we have seen how to compile a program by specializing an interpreter for a given source program: target = mix [int, source] Provided that we have a self-applicable partial evaluator, mix can be specialized for int: target = mix [mix, int] [source] = compiler [source] The program generated by self-specializing mix for int is without a doubt a stand-alone compiler, since its input is source and its output target. The equation: compiler = mix [mix, int] (2.2) is called the second Futamura projection Compiler-compiler generation Iterating the same process one more time will produce a compiler generator, a program that takes as input an interpreter, and outputs a compiler.

13 2.3 Online and offline specialization 13 compiler = mix [mix, int] = mix [mix, mix] [int] = cogen [int] The equation: cogen = mix [mix, mix] (2.3) is called the third Futamura projection. 2.3 Online and offline specialization Many different techniques can be used to achieve partial evaluation of a program, but most program specializers can be classified as being either online or offline. This section briefly defines the notions of online and offline specialization, and discusses the main differences between these approaches Decisions and specialization An essential task of a partial evaluator is, for a given program, to decide what computations are static and can be reduced at specialization time, and what computations are dynamic and must be postponed until run time (that is, residualized). The distinction between online and offline specializers relates to this decision phase. Online specializers make their decisions during program specialization, and are therefore free to use static values to improve their analyses, while offline specializers traditionnaly perform program analyzes before specialization, which must be done independently of concrete static values Online specialization With respect to the binding-time decisions mentioned above, online partial evaluation is a onestep process (see figure 2.5), where static values are inspected during specialization. As a consequence, the main advantages of online specialization are a more precise bindingtime separation, and a better quality of residual programs, because more informations are available to the specializer. Figure 2.5: Online specialization Figure 2.6 gives a simple example of a situation where a specializer can benefit from knowing static values. With e 1, e 2 being static and e 3 dynamic, a naive offline specializer must classify the whole conditional dynamic, whereas an online specializer can easily classify it as static if e 1 evaluates to true Offline specialization Offline specializers traditionnaly separate the specialization step from the binding-time separation step (see figure 2.7).

14 14 Of partial evaluation if e 1 ( static ) then e 2 ( static ) else e 3 ( dynamic ) Figure 2.6: Conditional with mixed binding-times Figure 2.7: Offline specialization First, a preprocessing phase is applied to the input program, to perform among other things its binding-time analysis. The informations needed for this stage are informations on which program inputs are static, and the result is an annotated program used afterwards by the offline specializer, when concrete values of static inputs are supplied. Terms: term ::= constant Constants operator Operators identifier Identifiers lift term Lifting term Static application λ identifier term Static abstraction if term then term else term Static conditional term Dynamic application λ identifier term Dynamic abstraction if term then term else term Dynamic conditional Figure 2.8: A two-level λ-calculus The annotated program produced by the binding-time analysis often takes the form of a program written in a two-level language, that offers both dynamic and static control structures, such as the two-level λ-calculus of figure 2.8. Multistage specialization and reuse One major drawback of offline partial evaluation, already seen above, is that it never takes into account values of static inputs to compute binding-time separations of programs, making this processing step lose some of its accuracy. Even so, this property can turn out to be an advantage. Because binding-time analysis is independent of values, it can as well be performed once for all for a given binding-time configuration, and reused for many different sets of concrete values. This is obviously very convenient for the execution scheme described in section 2.1.2, where a given program is specialized each time a specified set of variables is modified: the offline approach will bring a significant speedup, since only the execution of the annotated program has to be repeated. Binding-time annotations Dividing the partial evaluation process into two distinct stages increases the possible interaction with the user, in two different ways:

15 2.3 Online and offline specialization 15 The annotated program produced by the first computing step can be used to check the quality of the binding-time analysis, and help in tuning the binding-time properties of the source program. The specialization kernel can be fed with hand-written annotated programs, to achieve some particular behavior, or for experimentation purposes. Similarly, the user is free to modify the automatically annotated programs before their specialization.

16 16 Of partial evaluation

17 Chapter 3 Of template metaprogramming This chapter gives a partial overview of the field of C++ template metaprogramming. It especially focuses on the techniques used to achieve compile-time computations and efficient code generation by compile-time specialization. 3.1 Overview Over the last few years, many new programming techniques using template constructions have arised in the C++ community, all of which aimed at providing some forms of extensions to the language itself, or performing various program optimizations. Among other things, were developed improvements relative to typing [McNamara and Smaragdakis, 2000b], functional programming style [McNamara and Smaragdakis, 2000a], smart evaluation of arithmetic expressions [Veldhuizen, 1995], or compile-time computations, which came along with a large amount of libraries, such as Blitz++ [Blitz++], Pete [Pete], Fact! [Fact!], etc. The common trait of these libraries, often referred to as active or generative libraries, is the ability to produce extremely efficient code by the means of an extensive use of C++ templates, to achieve effects such as algorithm specialization or loop unrolling. Some of these static programming techniques, relevant to partial evaluation, are now discussed. 3.2 C++ as a two-level language The C++ template mechanism was at first introduced in the language to provide support for parametric polymorphism, mainly as a way of writing families of functions and classes, and as a replacement of C macros. But templates soon showed much more properties than intended. Indeed, templates are the core component of a static subset of C++, that is to say, a subset of C++ which is executed at compile-time. Hence, C++ has this striking property, among widespread languages, to be a two-level language, or, in other words, a language that provides both static constructs (used to control code production) and dynamic constructs (used to actually produce code). Moreover, the compiletime subset of C++ is Turing complete 1 [Czarnecki and Eisenecker, 2000], and there are therefore no theoretical limits to what can be computed at compile-time 2. 1 A language is said to be Turing complete when it provides a conditional construct and a looping construct. 2 Unfortunately, this is not yet the case in practice, see section 3.5.

18 18 Of template metaprogramming 3.3 Compile-time computations Using C++ as a two-level language offers to the programmer a wide amount of new possibilities. First of all, since the compiler behaves like an interpreter for the compile-time subset of the language, it becomes possible to achieve computations during compilation Factorial, or a basic example The most classic example of static computation is probably the factorial function. A usual implementation, using the dynamic part of C++, is shown in figure 3.1. unsigned factorial ( unsigned n) { if ( n == 0) return 1; else return n factorial ( n 1); factorial (4); Figure 3.1: Factorial with dynamic code In C++, the program mentioned above can be rewritten in the static subset of the language, as in figure 3.2. template < unsigned n > struct Factorial { static unsigned apply () { return n Factorial< n 1 >:: apply (); ; template < > struct Factorial < 0 > { static unsigned apply () { return 1; ; Factorial < 4 >:: apply (); Figure 3.2: Factorial with static code The main difference between these two flavors of the factorial function is their execution time. The dynamic form is a regular program, compiled and executed when the output program is invoked. The static form is executed at compile-time: none of its code is compiled, and the calls to factorial are instead replaced by the value they compute. Of course, the idea behind such static programs is to defer some of the computation to the compiler, perform it once for all, and gain some execution speed in the compiled program.

19 3.3 Compile-time computations Features of the static level The very simple example of the factorial function, seen above, has showed how a C++ compiler can be tricked and used to perform computations at compile-time. Now, how much expressive power does the static subset of C++ holds? Pattern matching Actually, static C++ is a full, yet very simple, language by itself, with a very strong functional flavor. As already stated above, it provides recursion, as shown with the factorial function, and a form of pattern matching (see figure 3.3). template < unsigned x > struct Matcher { ; template < > struct Matcher< 0 > { static unsigned apply () { return 1; ; template < > struct Matcher< 1 > { static unsigned apply () { return 0; ; Figure 3.3: Pattern matching in static C++ Bindings and immutable variables Like any purely functional language, static C++ does not provide any notion of state. Instead, the programmer will combine template parameters and template instanciations to encode bindings. The program of figure 3.4 shows the static declaration of a new variable xy, whose value is the sum of two variables x and y. template < unsigned x, unsigned y > struct A { static unsigned apply () { return B< x, y, x + y >:: apply (); ; template < unsigned x, unsigned y, unsigned xy > struct B { static unsigned apply () { return xy; ; Figure 3.4: Bindings in static C++ In its meaning, this program is of course very close to the regular C++ program shown in figure 3.5. { unsigned xy = x + y; return xy; Figure 3.5: Variables in regular C++

20 20 Of template metaprogramming Types as values Static C++ does not only treat integer values as data, but also types themselves. First of all, it allows to write functions operating over types, and also complex data structures using a fairly functional programming style. template < typename Head_ = void, typename Tail_ = void > struct List { typedef Head_ Head; typedef Tail_ Tail ; ; template < > struct List< void, void > { ; Figure 3.6: Static list in C++ Figure 3.6 shows how a list structure can be implemented with nested class templates, and figure 3.7 a simple operation over static lists. template < typename List > struct Length { static unsigned apply () { return Length< typename List::Tail >::apply () + 1; ; template < > struct Length< List< void, void > > { static unsigned apply () { return 0; ; Figure 3.7: Length of a static list in C Code generation and algorithm specialization So far, we have given some insight of how the template mechanism integrated in the C++ language can be used to perform compile-time computations. These techniques, however, would be of a limited interest if they could not be used in a partially static context. The key idea of active libraries, is to optimize algorithms by specializing them with respect to a given compilation context, usually supplied by the user: the size of a vector or matrix operation, some of the algorithm s input data, etc Mixing dynamic and static code To achieve results of this kind, the programmer can mix static code with dynamic code, in order to guide the compiler during code generation, instead of driving only fully static computations.

21 3.4 Code generation and algorithm specialization 21 Once again, a very simple example is exhibited to show the underlying principle. Consider the naive implementation of the power function shown in figure 3.8. unsigned power (unsigned x, unsigned n) { if ( n == 0) return 1; else if ( n == 1) return x; else return x power (x, n 1); Figure 3.8: Power with dynamic code This implementation of power is general. A unique instance of this code is compiled, and able to compute any power of any given number. Another approach is to write a code generator, that will produce a family of specialized functions. In this specific case, a programmer may write a partially static implementation of power, that will generate optimized code for any particular value of n. A program of this kind is given in figure 3.9. template < unsigned n > struct Power { static unsigned apply (unsigned x) { return x Power< n 1 >::apply (x); ; template < > struct Power< 1 > { static unsigned apply (unsigned x) { return x ; ; template < > struct Power< 0 > { static unsigned apply (unsigned x) { return 1; ; Figure 3.9: Power with partially static code The program is now written in a form where the compiler is fed with static information about n, and will produce an optimized version of power at template instanciation. The result of recursively inlining the power function is shown in figure std :: cout «Power< 4 >::apply (x ) «std :: endl; std :: cout «x Power< 3 >::apply (x ) «std :: endl; std :: cout «x x Power< 2 >::apply (x ) «std :: endl; std :: cout «x x x Power< 1 >::apply (x ) «std :: endl; std :: cout «x x x x «std :: endl; Figure 3.10: Template instanciations for the power function Example of compile-time optimization A constantly increasing number of C++ libraries use the techniques presented above to perform various compile-time specializations, and achieve in pratice impressive speedups, often compared with the Fortran language.

22 22 Of template metaprogramming We show here the results obtained with a benchmark of our own. The convolution program from section 1 is modified and turned into a template code generator. The two specialized forms of this program are now produced at compile-time, rather than using an external tool. The rest of the experimentation process remains unchanged. Figure 3.11: Convolution benchmark with static programming Execution times of the three programs are shown in figure Drawbacks The use of C++ as a two-level language has proven an invaluable tool, among other things for program specialization and performance issues. However, static programming in this language is possible only at the cost of many drawbacks Technical issues First, template metaprograms bring to the front some technical problems involving C++ compilers: Because compilation of template code becomes undecidable, compilers have to use heuristics to ensure termination, and tend to reduce a lot their tolerated template instanciation depth. With many compilers, this depth can be specified to a certain degree, but it still must be thought of as a limit for some computations. Even when a compiler can handle the programs it is given, the extensive use of template programming introduces a large increase of compile-times.

23 3.5 Drawbacks Maintenance of static programs In practice, the use of static programming in C++, especially when programs grow up in size, is made difficult by the syntax and the restrictions of the compile-time subset of the language. Writing programs at the static level is difficult in itself. Because the static sublanguage has a very reduced syntax, and is very different from regular C++, programs rapidly become rather obfuscated. For the same reasons, static programs are difficult to debug and maintain.

24 24 Of template metaprogramming

25 Chapter 4 Automatic program transformations This chapter describes the C++ program rewriting system we have implemented. It shows how a set of simple rewriting rules, designed to convert classic programs to their template metaprogram form, can be used to achieve automatic partial evaluation at low cost. 4.1 Motivation In chapter 2, we have given a brief introduction to partial evaluation, seen how this transformation technique can be used to speedup many programs, and the relationship between partial evaluation and multi-level languages in offline specialization. Chapter 3 was a short tour of so-called template metaprogramming techniques in the C++ language. We specifically focused on methods used in generative libraries to perform algorithm specialization at compile-time, and seen that such effects can be obtained because C++ is a twolevel language. Actually, it is a well-known fact, at least in the C++ community, that the C++ template mechanism is a form of offline partial evaluation, where the binding-time analysis step is carried out by hand by the programmer [Veldhuizen, 1999]. As a direct consequence, C++ compilers, which have to process in input two-level programs, are fully equiped to perform offline partial evaluation, but the whole process is far from the full automation available with traditional specializers. We propose here to make use of these properties to approach automatic partial evaluation of C++. Hence, instead of implementing a complete specializer, we choose to automate the work usually done by authors of active libraries, by providing a program rewriting system capable of transforming regular C++ programs into their template metaprogram form. 4.2 Generating template metaprograms This section presents some aspects of the prototype system we have implemented. Our tool is composed of a grammar specification of the C++ language, and of several sets of equations defining the transformations to perform on parse trees. Some of these equations are now presented, to give an insight of how our system works, rather than a precise description. For the same demonstrational purposes, the equations we give are as much as possible freed from unnecessary details. Equations defining how to rewrite classic C++ code into the static subset of the language form the core component of our system.

26 26 Automatic program transformations The main goal of this equation collection is to capture the essence of hand-driven template programming. For this reason, some of these equations are very close to transformations widely used by static C++ programmers, although they are written here in a much more general form, suitable for systematic application Functions In its current state, our system is centered around functions, and aims at being used in an algorithm-based paradigm. The equations defining how to transform functions are available in section A.1. The rather simple idea behind these equations is, for a given function, to separate static formal parameters from dynamic formal parameters. Dynamic parameters are left unchanged, but static parameters are shifted, becoming template parameters of a newly created function template. Moreover, these two sets of symbols are the starting point of the environments used when processing the function body. We call the static environment the variables declared at the static level, and the dynamic environment the variables declared at the dynamic level. Keeping track of these environments makes possible to split functions into collections of structure templates, as it it shown by our other equations Variables and state The equations defining how static variable declarations and assignments to static variables have to be transformed are shown in sections A.2.1 and A.2.2. To achieve the right transformations, most of our equations consider sequences of statements, rather than isolated program points. This is needed to ensure a correct information propagation, especially when splitting programs over the many template structures we produce. Since the static level of the C++ language does not provide any notion of state, static variables and assignments are handled by hand in the static environment. Each time a new variable is declared at the static level, and each time a variable of the static level is modified, the remaining part of the program is enclosed in a new structure template whose parameters are explicitly updated Control structures Sections A.3.1 and A.3.2 shows how if conditionals and while loops are transformed. They simply use pattern matching and template recursion to encode the right semantics. 4.3 Some results At the present time, our system is still in a very primitive form, but it has been successfully used to achieve the transformation of many small programs. Some examples of such programs are shown in this section Factorial, again To demonstrate the basic ideas behind our equations, we consider one more time the factorial function, written here in its recursive form (see figure 4.1). With n being marked as static, this program is transformed into the program shown in figure 4.2, very similar to the hand-written factorial function from figure 3.2.

27 4.4 Benefits of this approach 27 unsigned factorial ( unsigned n) { if ( n == 0) return 1; else return factorial ( n 1) n; Figure 4.1: Factorial before transformation template < int n > struct Jump 1 { int apply () { ; template < int n, bool cond > struct Cond 0 { int apply () { return 1; return Jump 1< n >::apply (); ; template < int n > struct Cond 0< n, false > { int apply () { return factorial < (n 1) > () n; return Jump 1< n >::apply (); ; template < int n > int factorial () { return Cond 0< n, (n == 0) >::apply (); Figure 4.2: Factorial after transformation Yet another power algorithm The following example demonstrates transformations of partially static computations, and how the dynamic environment is managed when spanning a function over several structures. unsigned power (unsigned x, unsigned n) { if ( n == 0) return 1; else if (( n % 2) == 0) { unsigned r = power (x, n / 2); return r r ; else return power (x, n 1) x; Figure 4.3: Power before transformation By rewriting the power function show in figure 4.3 with x being marked as dynamic, and n being marked as static, the program from figure 4.4 is obtained Imperative style Last, we show how a program using imperative style is converted into its template form. We transform a different implementation of power, shown in figure 4.5, but use the same binding-time configuration than in the previous example (n is static). The result is shown in figure Benefits of this approach Using the C++ language itself as a back-end for program specialization has several advantages over traditional partial evaluation, inherited from the static metaprogramming techniques.

28 28 Automatic program transformations template < int n > struct Jump 1 { int apply (int &x) { ; template < int n > struct Jump 3 { int apply (int &x) { return Jump 1< n >::apply (x); ; template < int n, bool cond > struct Cond 2 { int apply (int &x) { int r = power< (n / 2) > (x ); return r r ; return Jump 3< n >::apply (x); ; template < int n > struct Cond 2 { int apply (int &x) { return power< (n 1) > (x) x; return Jump 3< n >::apply (x); ; template < int n, bool cond > struct Cond 0 { int apply (int &x) { return 1; return Jump 1< n >::apply (x); ; template < int n > struct Cond 0< n, false > { int apply (int &x) { return Cond 2< n, ((n % 2) == 0) >::apply (x); ; template < int n > int factorial ( int x ) { return Cond 0< n, (n == 0) >::apply (x); Figure 4.4: Power after transformation int power (int x, int n) { int r = 1; while (n > 0) { r = r x; n = n 1; return r ; Figure 4.5: Imperative power before transformation Once the program analysis and transformation stage is finished, there is no need for dedicated tools to perform specialization. The generated metaprogram can be distributed, as this is done in the C++ community with so-called generative or active libraries, and specialized by the end-user at compile-time for the invariants he needs. Invariants are provided in a consistent way, using the static subset of C++. Since this form of program specialization is native to the C++ language, it can be easily mixed with other C++ specific programming techniques, and especially be used in the generic programming paradigm [Géraud, 2002]. Our program transformation approach, by its very nature, also brings several improvements to classic template metaprogramming techniques: Because most of the programmer s work is done on regular C++ programs, the readability problems encountered with static metaprogramming are avoided. Precisely for the same reason, debugging problems are avoided as well, since programs can be tested and modified at will before transformation.

29 4.5 Limitations 29 template < int n > struct Jump 1 { int apply (int &x, int &r ) { return r ; ; template < int n > struct Update 2 { int apply (int &x, int &r ) { return Loop 0< n, (n > 0) >::apply (x, r ); ; template < int n > struct Loop 0< n, false > { int apply (int &x, int &r ) { return Jump 1< n >::apply (x, r); ; template < int n > power (int x) { int r = 1; return Loop 0< n, (n > 0) >::apply (x, r ;) template < int n, bool cond > struct Loop 0 { int apply (int &x, int &r ) { r = r x; return Update 2< (n 1) >::apply (x, r); ; 4.5 Limitations Figure 4.6: Imperative power after transformation Limitations and drawbacks of our approach are mostly the same as those encountered when working with usual template metaprograms. Various compiler limitations might prevent the use of generated programs. Compilation times are greatly increased by the many template instanciations needed to perform program specialization. This slowdown is a natural consequence of performing a part of the program computations before run time, but a real partial evaluator would probably be more efficient than a C++ compiler. 4.6 Further work As it already has been mentioned in this section, the tool being used in our approach to partial evaluation is in a very early prototype stage, and a lot of work remains to reach an industrialstrength system Full language support First, all of our specifications have to be completed. This is true for our various equation sets, but also for the grammar specification we are working with Object-oriented specialization Until now, we have only considered the use of our tool in an algorithm based paradigm. Much work has to be done to generalize partial evaluation to object-oriented programming in general [Schultz, 2000], and to extend our program transformation approach in the same fashion.

30 30 Automatic program transformations

31 Chapter 5 Conclusion After describing partial evaluation and C++ static programming, we have put forward the idea that, by taking advantage of some of the surprising, but powerful properties of C++, simple program transformations can lead to a convenient and automatic form of partial evaluation for this language. Moreover, the development of a very simple but working prototype dedicated to this task, has proved that these transformations are possible, and that they only are a generalization of the techniques inherited from the C++ community, made suitable for a systematic application. In addition to this, the idea of using automatic transformations on the C++ language, gives birth to a new perspective on the many metaprogramming techniques we did not cover in this report, such as static class hierarchies or expression templates, for which there also exists possibilities of automation.

32 32 Conclusion

33 Chapter 6 Bibliography Blitz++. Homepage of the blitz++ project. C-Mix. Homepage of the c-mix project. activities/cmix/. K. Czarnecki and U. W. Eisenecker. Generative Programming; Methods, Tools, and Applications. Addison-Wesley, Fact! Homepage of the fact! project. index.html. Y. Futamura. Partial evaluation of computation process; an approach to a compiler-compiler, T. Géraud. Towards statically type-safe programming with the c++ language, Available on demand. N. D. Jones, C. K. Gomard, and P. Sestoft. Partial Evaluation and Automatic Program Generation. Prentice Hall International, B. McNamara and Y. Smaragdakis. Functional programming in c++, 2000a. B. McNamara and Y. Smaragdakis. Static interfaces in c++, 2000b. Pete. Homepage of the pete project. U. P. Schultz. Object-oriented software engineering using partial evaluation, T. Veldhuizen. Expression templates, T. Veldhuizen. C++ templates as partial evaluation, 1999.

34 34 BIBLIOGRAPHY

35 Appendix A Equations This appendix contains some of the equations used in our program rewriting system to define how usual C++ programs are transformed into their static versions. A.1 Functions [tr-func] tr (T I (P s ) { S s ) = template < S > struct Fun { R apply (D) { tr (S s ) ; where R is T S is the static part of P s D is the dynamic part of P s A.2 Variables and state A.2.1 Static declarations [tr-state-1] tr (T I = E; E s ) = template < S + {I : T > where I is static struct Let { R apply (D) { tr (E s ) ; return Let< S + {I : E >::apply (D );

36 36 Equations A.2.2 Assignments to static variables [tr-state-2] tr (I = E; E s ) = template < S > where I is static struct Update { R apply (D) { tr (E s ) ; return Update< S {I : E >::apply (D ); A.3 Control structures A.3.1 Conditionals [tr-ctrl-if] tr ( = template < S + {cnd : bool > if (E) struct If { S 1 else R apply (D) { S 2 tr ( E s S 1 ; ) return Merge< S >::apply (D ); where E is static ) ; template < S > struct If< S, false > { R apply (D) { tr ( S 2 ; return Merge< S >::apply (D ); ) ; template < S > struct Merge { R apply (D) { tr (E s ) ; return Update< S + {cnd : E >::apply (D );

37 A.3 Control structures 37 A.3.2 Loops [tr-ctrl-while] tr ( = template < S + {cnd : bool > while (E) struct While { S E s R apply (D) { ) tr ( where E is static S; return While< S + {cnd : E >::apply (D ); ) ; template < S > struct While< S, false > { R apply (D) { tr ( return End< S >::apply (D ); ) ; template < S > struct End { R apply (D) { tr(e s ) ; return While< S + {cnd : E >::apply (D );