Difference between revisions of "Papers"
Hzwakenberg (talk | contribs) m |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category: Literature]] |
||
| − | Those papers were written for SmallEiffel and SmartEiffel, but they still give good insights on the workings of Liberty Eiffel. |
||
| + | These research papers were written for the legacy SmallEiffel and SmartEiffel compilers, but they still give good insights into the workings of Liberty Eiffel. |
||
== Type Inference for Late Binding. The SmallEiffel Compiler == |
== Type Inference for Late Binding. The SmallEiffel Compiler == |
||
| Line 11: | Line 12: | ||
The SmallEiffel compiler uses a simple type inference mechanism to translate Eiffel source code to C code. The most important aspect in our technique is that many occurrences of late binding are replaced by static binding. Moreover, when dynamic dispatch cannot be removed, inlining is still possible. The advantage of this approach is that is speeds up execution time and decreases considerably the amount of generated code. SmallEiffel compiler source code itself is a large scale benchmark used to show the quality of our results. Obviously, this efficient technique can also be used for class-based languages without dynamic class creation: for example, it is possible for C++ or Java and not possible for SmallTalk. |
The SmallEiffel compiler uses a simple type inference mechanism to translate Eiffel source code to C code. The most important aspect in our technique is that many occurrences of late binding are replaced by static binding. Moreover, when dynamic dispatch cannot be removed, inlining is still possible. The advantage of this approach is that is speeds up execution time and decreases considerably the amount of generated code. SmallEiffel compiler source code itself is a large scale benchmark used to show the quality of our results. Obviously, this efficient technique can also be used for class-based languages without dynamic class creation: for example, it is possible for C++ or Java and not possible for SmallTalk. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/jmlc97.pdf Download the entire article] |
| Line 22: | Line 23: | ||
'''Abstract:''' |
'''Abstract:''' |
||
| − | SmallEiffel is an Eiffel compiler which uses a fast simple inference mechanism to remove most |
+ | SmallEiffel is an Eiffel compiler which uses a fast, simple inference mechanism to remove most late binding calls, replacing them by static bindings. Starting from the system's entry point, it compiles only statically living code, which saves compiling and then removing dead code. As the whole system is analyzed at compile time, multiple inheritance and genericity do not cause any overhead. |
| − | SmallEiffel features a coding scheme which eliminates the need for virtual function tables. Dynamic dispatch is implemented without any array access but uses a simple static binary branch code. We show that this implementation makes it possible to use modern hardware very efficiently. It also allows to inline more calls even when dynamic dispatch is required. Some more dispatch sites are removed after the type inference algorithm has been performed, if the different branches of a dispatch site lead to the same code. |
+ | SmallEiffel features a coding scheme which eliminates the need for virtual function tables. Dynamic dispatch is implemented without any array access, but uses a simple static binary branch code. We show that this implementation makes it possible to use modern hardware very efficiently. It also allows to inline more calls even when dynamic dispatch is required. Some more dispatch sites are removed after the type inference algorithm has been performed, if the different branches of a dispatch site lead to the same code. |
The advantage of this approach is that it greatly speeds up execution time and considerably decreases the amount of generated code. |
The advantage of this approach is that it greatly speeds up execution time and considerably decreases the amount of generated code. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/oopsla97.pdf Download the entire article] |
| − | |||
== Compiler Support to Customize the Mark and Sweep Algorithm. == |
== Compiler Support to Customize the Mark and Sweep Algorithm. == |
||
| Line 45: | Line 45: | ||
We present the results obtained on programs featuring a variety of programming styles and compare our results to a well-know and high quality garbage collector. |
We present the results obtained on programs featuring a variety of programming styles and compare our results to a well-know and high quality garbage collector. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/ismm98.pdf Download the entire article] |
| Line 58: | Line 58: | ||
The design of the Eiffel language makes it possible to perform global optimizations on Eiffel programs. In this paper, we describe some of the techniques we used in SmallEiffel, The GNU Eiffel Compiler, to generate highly efficient executables for Eiffel programs. Most of these techniques --- related to global analysis or not --- may also be applied to other object-oriented languages. |
The design of the Eiffel language makes it possible to perform global optimizations on Eiffel programs. In this paper, we describe some of the techniques we used in SmallEiffel, The GNU Eiffel Compiler, to generate highly efficient executables for Eiffel programs. Most of these techniques --- related to global analysis or not --- may also be applied to other object-oriented languages. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/tools-europe-99.pdf Download the entire article] |
| Line 71: | Line 71: | ||
This paper discusses common iteration schemes and highlights the interest of using explicit iterators. The advantages of external iterators are compared to those of internalized iterators. The integration of an iterator class hierarchy to an existing library without modifying the latter is detailed. This integration brings an extra level of abstraction to the library, which thus becomes more flexible, more adapted to certain design patterns and hence can be used in a higher-level way. Such an integration is not only possible, but can even be done in an optimized way, taking into account the specific structure of the collection traversed. A slight extension of existing class libraries can also be implemented that does not cause any compatibility problem and does not break existing code, but allows even further abstraction and makes it easier for the developer to use high-level, optimized, external iterators. |
This paper discusses common iteration schemes and highlights the interest of using explicit iterators. The advantages of external iterators are compared to those of internalized iterators. The integration of an iterator class hierarchy to an existing library without modifying the latter is detailed. This integration brings an extra level of abstraction to the library, which thus becomes more flexible, more adapted to certain design patterns and hence can be used in a higher-level way. Such an integration is not only possible, but can even be done in an optimized way, taking into account the specific structure of the collection traversed. A slight extension of existing class libraries can also be implemented that does not cause any compatibility problem and does not break existing code, but allows even further abstraction and makes it easier for the developer to use high-level, optimized, external iterators. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/tools-pacific-1999.pdf Download the entire article] |
| Line 86: | Line 86: | ||
Although they can be seen as normal objects, they convey specific issues, pertaining to standard conformance rules for generic types. To get rid of existing problems, this paper proposes an adaptation of conformance rules for agents that provides much more flexibility while retaining all the benefits of a strong static typing system. |
Although they can be seen as normal objects, they convey specific issues, pertaining to standard conformance rules for generic types. To get rid of existing problems, this paper proposes an adaptation of conformance rules for agents that provides much more flexibility while retaining all the benefits of a strong static typing system. |
||
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/jot2004.pdf Download the entire article] |
| − | [http://www.jot.fm/issues/issue_2004_04/article7 |
+ | [http://www.jot.fm/issues/issue_2004_04/article7 HTML version at the JOT web site] |
== Non-Conforming Inheritance: the SmartEiffel Experiment of a High-Level Mechanism == |
== Non-Conforming Inheritance: the SmartEiffel Experiment of a High-Level Mechanism == |
||
| Line 97: | Line 97: | ||
'''Abstract:''' |
'''Abstract:''' |
||
| − | Non-conforming inheritance (NC-inheritance) is a mechanism recently introduced in the new Eiffel definition. The NC-inheritance mechanism is similar to traditional inheritance but it disallows polymorphism. This simple mechanism appears to be useful in many situations because it allows the designer to capture more design decisions in the source code itself. Furthermore this mechanism helps compilers to statically remove more dynamic dispatch code. NC-inheritance incurs no type-system soundness problems even when arguments are redefined covariantly or when the exportation is restricted in the subclass. Out of the Eiffel world, the NC-inheritance mechanism can be useful to add a no-penalty and no-risk multiple-inheritance-like facility. For instance the Java language, initially designed for simple-inheritance, could be a possible candidate for an NC- |
+ | Non-conforming inheritance (NC-inheritance) is a mechanism recently introduced in the new Eiffel definition. The NC-inheritance mechanism is similar to traditional inheritance but it disallows polymorphism. This simple mechanism appears to be useful in many situations because it allows the designer to capture more design decisions in the source code itself. Furthermore, this mechanism helps compilers to statically remove more dynamic dispatch code. NC-inheritance incurs no type-system soundness problems even when arguments are redefined covariantly or when the exportation is restricted in the subclass. Out of the Eiffel world, the NC-inheritance mechanism can be useful to add a no-penalty and no-risk multiple-inheritance-like facility. For instance, the Java language, initially designed for simple-inheritance, could be a possible candidate for an NC-inheritance extension. |
| − | [ |
+ | [http://www.liberty-eiffel.org/papers/insert2005.pdf Download the entire article] |
Latest revision as of 13:10, 15 April 2022
These research papers were written for the legacy SmallEiffel and SmartEiffel compilers, but they still give good insights into the workings of Liberty Eiffel.
Type Inference for Late Binding. The SmallEiffel Compiler
Suzanne COLLIN, Dominique COLNET and Olivier ZENDRA
Joint Modular Languages Conference 1997 (JMLC'97), Volume 1204 of Lecture Notes in Computer Sciences, pages 67-81.
Abstract:
The SmallEiffel compiler uses a simple type inference mechanism to translate Eiffel source code to C code. The most important aspect in our technique is that many occurrences of late binding are replaced by static binding. Moreover, when dynamic dispatch cannot be removed, inlining is still possible. The advantage of this approach is that is speeds up execution time and decreases considerably the amount of generated code. SmallEiffel compiler source code itself is a large scale benchmark used to show the quality of our results. Obviously, this efficient technique can also be used for class-based languages without dynamic class creation: for example, it is possible for C++ or Java and not possible for SmallTalk.
Efficient Dynamic Dispatch without Virtual Function Tables. The SmallEiffel Compiler.
Olivier ZENDRA, Dominique COLNET, Suzanne COLLIN.
12th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'97), Volume 32, Issue 10 --- Atlanta, GA, USA, October 1997, pages 125-141.
Abstract:
SmallEiffel is an Eiffel compiler which uses a fast, simple inference mechanism to remove most late binding calls, replacing them by static bindings. Starting from the system's entry point, it compiles only statically living code, which saves compiling and then removing dead code. As the whole system is analyzed at compile time, multiple inheritance and genericity do not cause any overhead.
SmallEiffel features a coding scheme which eliminates the need for virtual function tables. Dynamic dispatch is implemented without any array access, but uses a simple static binary branch code. We show that this implementation makes it possible to use modern hardware very efficiently. It also allows to inline more calls even when dynamic dispatch is required. Some more dispatch sites are removed after the type inference algorithm has been performed, if the different branches of a dispatch site lead to the same code.
The advantage of this approach is that it greatly speeds up execution time and considerably decreases the amount of generated code.
Compiler Support to Customize the Mark and Sweep Algorithm.
Dominique COLNET, Philippe COUCAUD and Olivier ZENDRA.
ACM SIGPLAN International Symposium on Memory Management (ISMM'98), Vancouver, BC, Canada, October 17-19, 1998, pages 154-165.
Abstract:
Mark and sweep garbage collectors (GC) are classical but still very efficient automatic memory management systems. Although challenged by other kinds of systems, such as copying collectors, mark and sweep collectors remain among the best in terms of performance.
This paper describes our implementation of an efficient mark and sweep garbage collector tailored to each program. Compiler support provides the type information required to statically and automatically generate this customized garbage collector. The segregation of objects by type allows the production of a more efficient GC code. This technique, implemented in SmallEiffel, our compiler for the object-oriented language Eiffel, is applicable to other languages and other garbage collection algorithms, be they distributed or not.
We present the results obtained on programs featuring a variety of programming styles and compare our results to a well-know and high quality garbage collector.
Optimizations of Eiffel programs: SmallEiffel, The GNU Eiffel Compiler.
Dominique COLNET and Olivier ZENDRA.
29th conference on Technology of Object-Oriented Languages and Systems (TOOLS Europe'99), IEEE Computer Society Nancy, France, June 7-10, 1999, pages 341--350.
Abstract:
The design of the Eiffel language makes it possible to perform global optimizations on Eiffel programs. In this paper, we describe some of the techniques we used in SmallEiffel, The GNU Eiffel Compiler, to generate highly efficient executables for Eiffel programs. Most of these techniques --- related to global analysis or not --- may also be applied to other object-oriented languages.
Adding external iterators to an existing Eiffel class library.
Olivier ZENDRA and Dominique COLNET.
32nd conference on Technology of Object-Oriented Languages and Systems (TOOLS Pacific'99), IEEE Computer Society Melbourne, Australia, 22-25 November 1999, pages xx--yy.
Abstract:
This paper discusses common iteration schemes and highlights the interest of using explicit iterators. The advantages of external iterators are compared to those of internalized iterators. The integration of an iterator class hierarchy to an existing library without modifying the latter is detailed. This integration brings an extra level of abstraction to the library, which thus becomes more flexible, more adapted to certain design patterns and hence can be used in a higher-level way. Such an integration is not only possible, but can even be done in an optimized way, taking into account the specific structure of the collection traversed. A slight extension of existing class libraries can also be implemented that does not cause any compatibility problem and does not break existing code, but allows even further abstraction and makes it easier for the developer to use high-level, optimized, external iterators.
Conformance of agents in the Eiffel language
Philippe Ribet, Cyril Adrian, Olivier Zendra, and Dominique Colnet
Conference on Technology of Object-Oriented Languages and Systems (TOOLS USA 2003) Published in Journal Of Technology (JOT), April 2004.
Abstract:
In Eiffel, the notion of agent makes it possible to describe and manipulate computation parts (i.e. operations) like ordinary data. Operations may be partially described, may be passed as ordinary data and may have their execution delayed. Agents are very convenient for many purposes, such as going through data structures and implementing call-backs in graphical libraries.
Although they can be seen as normal objects, they convey specific issues, pertaining to standard conformance rules for generic types. To get rid of existing problems, this paper proposes an adaptation of conformance rules for agents that provides much more flexibility while retaining all the benefits of a strong static typing system.
HTML version at the JOT web site
Non-Conforming Inheritance: the SmartEiffel Experiment of a High-Level Mechanism
Frederic Merizen, Dominique Colnet, Philippe Ribet and Cyril Adrian
Rejected submission for OOPSLA 2005.
Abstract:
Non-conforming inheritance (NC-inheritance) is a mechanism recently introduced in the new Eiffel definition. The NC-inheritance mechanism is similar to traditional inheritance but it disallows polymorphism. This simple mechanism appears to be useful in many situations because it allows the designer to capture more design decisions in the source code itself. Furthermore, this mechanism helps compilers to statically remove more dynamic dispatch code. NC-inheritance incurs no type-system soundness problems even when arguments are redefined covariantly or when the exportation is restricted in the subclass. Out of the Eiffel world, the NC-inheritance mechanism can be useful to add a no-penalty and no-risk multiple-inheritance-like facility. For instance, the Java language, initially designed for simple-inheritance, could be a possible candidate for an NC-inheritance extension.