| © 1998 IRISA / INRIA - University of Rennes 1 |
Version |
Partial evaluation is a program transformation approach which is applicable to a large class of programming languages. Although this simple statement is well-accepted in the community, for many years, most research efforts focused on the partial evaluation of prototype languages, instead of widely used languages. As a result, until recently, the potentials of partial evaluation had mainly been demonstrated on toy examples. This situation often led to consider partial evaluation as a minor topic considering the lack of impact it had as a technique (or tool) on other research areas.
The need to go beyond a specific programming language in studying partial evaluation became clear to me when I arrived at Oregon Graduate Institute in 1992 and started collaborating with a group of operating system researchers, led by Calton Pu and Jonathan Walpole. Surprisingly, they were interested in investigating the use of partial evaluation in an operating system. Since I was then working on a partial evaluator for pure Scheme programs (Schism), I naturally attempted to promote functional programming for this project (later named Synthetix). In fact, soon enough, we realized that a functional language would lead us, not only to work on partial evaluation problems raised by operating systems, but also to address implementation problems of functional languages (some of these issues have been studied by the Fox project at CMU).
As a consequence, we decided to use a language whose implementation fulfilled the basic requirements of operating systems so as to focus our effort on the partial evaluation aspects of the study --- not the language design and implementation aspects. In this context, the C language seemed a natural choice. Because a language like C is widely used, the design and implementation of a partial evaluator could be attacked from a new viewpoint: instead of guessing interesting problems, the partial evaluator could be developed with some practical goals in mind. Indeed, the variations in designing and implementing a partial evaluator are boundless; as a tool, what makes a good partial evaluator is its usefulness. That is, it should offer a set of features that enables it to successfully handle practical situations. Because various domains require various features, and given my undergoing collaboration in operating system, I initially restricted my study to systems programs.
In fact, targeting a particular domain brought up a lot of new and challenging problems that I could not have come up with by myself. In my opinion, the most interesting problem which came up certainly was the need to specialize programs at run time. This need arose when we studied the specialization of the Unix file system. The idea was to use specialization values which are only available when a file is opened, that is at run time. There were clear opportunities for specialization but the technology only permitted programs to be specialized at compile time. This situation later led a student and myself to develop a template-based approach to perform specialization at run time.
When I arrived at Irisa in 1993, my immediate goal was to start the design and development of a partial evaluator for C. In fact, it took more than a year of preliminary study to actually launch the project. The design and development of Tempo started in 1994. The group of people working on Tempo, besides myself, then included Luke Hornof, François Noël, Jacques Noyé and Nic Volanschi. Later Gilles Muller and Renaud Marlet joined the team. Gilles Muller brought his expertise in operating systems to make Tempo's features suitable for the needs of systems programs. He lead the work aimed at specializing the Sun RPC. Renaud Marlet brought his expertise in programming languages and software engineering. He studied software architectures in the context of partial evaluation. Besides, he organized and made major contributions to the development of Tempo.
The partial evaluation principles and techniques developed in the context of simple languages like a pure version of Scheme represented a valuable basis on which our partial evaluator for C could rely. In fact, our approach aimed at applying the basic design and implementation techniques developed for Schism. It seemed obvious to me that there was nothing in principle which would forbid the re-use of this work. Of course, other aspects were completely unexplored territory. These aspects mainly included the imperative features C (most notably pointers), and the features specific to the systems programs.
The first successful specialization of an existing real-size application occurred in January 1997 with the specialization of the XDR layers of the Sun RPC. Other notable successful applications since then include GAL (a domain-specific language for video device drivers) and, featuring run-time specialization, the specialization of some system layers in the Chorus IPC and the PLAN-P on-the-fly compiler (Active Network language for application protocols).
The first Tempo workshop was organized on March 16-18, 1998. This successful spring school gathered 24 academic and industrial participants. Part of the course material is available on-line.
This workshop was the prelude to Tempo's first release. The original name, which was just Tempo, had to be changed to Tempo Specializer because of existing registered trade marks.
Tempo Specializer was first released in April 1998 to the participants of the workshop, as well as to other people that had shown earlier interest to our work. We plan to make a broader distribution in May or June 1998.
Here is the list of people that had the most important impact on Tempo and their main contributions. These lists of contributions are of course incomplete, for Tempo is also the result of many group discussions.
I accept all consequences regarding the above side comments -- Renaud.
tempo-talk@irisa.fr
tempo@irisa.fr
http://compose.labri.fr
tempo