Previous | Table of Contents | Next |
Note that the design of Java VM does not permit reference to the actual address of the data within a structure. The field total is fetched by name rather than by specifying its location in memory. This apparent inefficiency is designed into Java VM in support of separate compilation. Suppose the structure containing total were to be reorganized; then any reference to the field total by its offset within an object instance would have to be corrected, either by recomputation at runtime or by recompilation of the source program containing the object reference. By cleverly engineering the IL, Java objects can be compiled independently. This is important because the objects, which may be defined at physically separated locations, can still interoperate correctly without recompilation. Implementations of Java VM are free to optimize object references into hardcoded offsets (addresses within a structure), but it is important that the Java IL interface not allow the direct expression of addresses.
On the other hand, consider the Java source fragment from a public class
test: switch (x) case sym.bar: y=x+1; }
The reference to class syms public bar field appears in Java VM IL as a constant value that is obtained at the time test is compiled. If class sym is modified so that bars value changes, then the code in the test class is no longer valid because it incorporated the value of sym.bar at compile time. With no reference in class test to sym.bar, the switch statements staleness cannot be discovered. This problem arises because the IL mechanism for expressing the switch statement requires that the case values be specified as integer constants. This problem could be solved by
Intermediate languages are an important and yet often hidden aspect of system software. Their careful construction allows software to be robust, portable, and efficient. As software components such as language translators, debuggers, programming environments, and visualization tools continue their trend toward interoperability, reasonable IL design will continue to be an important activity. Once designed and published, ILs will also serve as breeding grounds for new kinds of tools that span traditional software boundaries.
The author is grateful to David Hemmendinger and Anthony Ralston for their comments on an earlier version of this material and to Michael Plezbert for his careful reading and comments on this material. Kitty Jarretts editing greatly improved this chapter. The author also thanks Fran Allen of IBM Research for many enlightening conversations concerning the nature of intermediate languages. She has profoundly influenced the fieldand especially this author.
Chow, F. C., and M. Ganapathi. 1983. Intermediate languages in compiler constructionA bibliography. Sigplan Notices 18(11):2123.
Fischer, C., and R. LeBlanc. 1991. Crafting a compiler with C. Redwood City, CA: Benjamin/Cummings.
Hansen, P. B. 1985. Brinch Hansen on Pascal compilers. Englewood Cliffs, NJ: Prentice-Hall.
Jensen, K., and N. Wirth. 1975. Pascal user manual and report. New York: Springer-Verlag.
Lamport, L. 1995. LaTeX: A document preparation system. Reading, MA: Addison-Wesley.
Lindholm, T., and F. Yellin. 1997. The Java virtual machine specification. Reading, MA: Addison-Wesley.
OBrien, K., K. OBrien, M. Hopkins, A. Shepherd, and R. Unrau. 1995. XIL and YIL: The intermediate languages of TOBEY. ACM SIGPLAN Notices 30(3):7182.
Ottenstein, K. J. 1984. Intermediate languages in compiler constructionA supplemental bibliography. Sigplan Notices 19(7):2527.
Stallman, R. Using and porting GNU CC. http://www.fsf.org.
Stroustrup, B. 1994. The design and evolution of C++. Reading, MA: Addison-Wesley.
Welsh, J., and A. Hay. 1986. A model implementation of standard Pascal. Englewood Cliffs, NJ: Prentice-Hall.
Previous | Table of Contents | Next |