Package harpoon.Interpret.Tree

An interpreter for tree form.

See:
          Description

Class Summary
DefaultFrame The DefaultFrame class implements the abstract methods of the Frame class.
INClass INClass provides implementations of the native methods in java.lang.Class.
INFile INFile provides implementations for (some of) the native methods in java.io.File.
INFloatDouble INFloatDouble provides implementations of the native methods in java.lang.Float and java.lang.Double.
INObject INObject provides implementations of the native methods in java.lang.Object.
INRuntime INRuntime provides implementations of the native methods in java.lang.Runtime.
INString INString provides implementations of the native methods in java.lang.String.
InterfaceList The InterfaceList class is a linked list used to represent a list of interfaces.
InterfaceListPointer The InterfaceListPointer is used to representing a pointer to a list of interfaces.
InterpreterOffsetMap A simple OffsetMap, used by the Tree Interpreter
Method Method converts HMethods into tree code, and interprets them.
StringPointer The StringPointer class represents a pointer to an string constant.
TestRun Run invokes the interpreter.
UndefinedPointer The UndefinedPointer class represents a pointer to a value for which the type is not known.
UndefinedRef UndefinedRef is a reference of an unknown type
 

Exception Summary
PointerTypeChangedException This exception is thrown when the type of a Pointer within the Tree interpreter is changed.
 

Package harpoon.Interpret.Tree Description

An interpreter for tree form. Uses Java's built-in garbage collection and run-time to serve as the run-time for the interpreted code. Outputs profiling information and statistics if you ask nicely. Currently handles only canonical tree form. It is unclear to me that there is any benefit to supporting an interpreter for tree with ESEQ, but if there is enough demand, perhaps I will get around to it. The interpreter is similar to the quad interpreter. The main differences are:

The similarities of the interpreters may warrant eventually unifying them under a set of common superclasses.

Author:
C. Scott Ananian <cananian@alumni.princeton.edu>, Duncan Bryce <duncan@lcs.mit.edu>