Results 1 -
4 of
4
A Calculus for Compiling and Linking Classes
, 2000
"... . We describe ink& (pronounced "links"), a low-level calculus designed to serve as the basis for an intermediate representation in compilers for class-based object-oriented languages. The primitives in ink& can express a wide range of class-based object-oriented language features, including vario ..."
Abstract
-
Cited by 19 (0 self)
- Add to MetaCart
. We describe ink& (pronounced "links"), a low-level calculus designed to serve as the basis for an intermediate representation in compilers for class-based object-oriented languages. The primitives in ink& can express a wide range of class-based object-oriented language features, including various forms of inheritance, method override, and method dispatch. In particular, ink& can model the object-oriented features of MOBY, OCAML, and LOOM, where subclasses may be derived from unknown base classes. ink& can also serve as the intermediate representation for more conventional class mechanisms, such as JAVA's. In this paper, we formally describe ink& , give examples of its use, and discuss how standard compiler transformations can be used to optimize programs in the ink& representation. 1 Introduction Class-based object-oriented languages provide mechanisms for factoring code into a hierarchy of classes. For example, the implementation of a text window may be split into a base ...
Software and Hardware Techniques for Efficient Polymorphic Calls
, 1999
"... Object-oriented code looks different from procedural code. The main difference is the increased frequency of polymorphic calls. A polymorphic call looks like a procedural call, but where a procedural call has only one possible target subroutine, a polymorphic call can result in the execution of one ..."
Abstract
-
Cited by 11 (1 self)
- Add to MetaCart
Object-oriented code looks different from procedural code. The main difference is the increased frequency of polymorphic calls. A polymorphic call looks like a procedural call, but where a procedural call has only one possible target subroutine, a polymorphic call can result in the execution of one of several different subroutines. The choice is made at run time, and depends on the type of the receiving object (the first argument). Polymorphic calls enable the construction of clean, modular code design. They allow the programmer to invoke operations on an object without knowing its exact type in advance. This flexibility incurs an overhead: in general, polymorphic calls must be resolved at run time. The overhead of this run time polymorphic call resolution can lead a programmer to sacrifice clarity of design for more efficient code, by replacing instances of polymorphic calls by several single-target procedural calls, removing run time polymorphism. This practice typically leads to a m...
Multi-Method Dispatch Using Multiple Row Displacement
- LNCS
, 1999
"... Multiple Row Displacement (MRD) is a new dispatch technique for multi-method languages. It is based on compressing an n-dimensional table using an extension of the single-receiver row displacement mechanism. This paper presents the new algorithm and provides experimental results that compare it with ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
Multiple Row Displacement (MRD) is a new dispatch technique for multi-method languages. It is based on compressing an n-dimensional table using an extension of the single-receiver row displacement mechanism. This paper presents the new algorithm and provides experimental results that compare it with implementations of existing techniques: compressed n-dimensional tables, look-up automata and single-receiver projection. MRD uses comparable space to the other techniques, but has faster dispatch performance.
Reconciling Encapsulation and Dynamic Dispatch via Accessory Functions
, 1999
"... Many object-oriented languages allow encapsulation of data. We identify a conflict between data encapsulation and dynamic dispatch, and propose that it be resolved via the addition of "accessory functions". We discuss the implementation of accessory functions for C++, and show that this system exten ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Many object-oriented languages allow encapsulation of data. We identify a conflict between data encapsulation and dynamic dispatch, and propose that it be resolved via the addition of "accessory functions". We discuss the implementation of accessory functions for C++, and show that this system extends naturally to allow multiple dispatch in C++.

