WO2002048864A2

WO2002048864A2 - System registers for an object-oriented processor

Info

Publication number: WO2002048864A2
Application number: PCT/US2001/043957
Authority: WO
Inventors: Thomas Bottomley
Original assignee: Zucotto Wireless, Inc.
Priority date: 2000-11-20
Filing date: 2001-11-20
Publication date: 2002-06-20
Also published as: AU2002241507A1; WO2002048864A3; WO2002048864A8

Abstract

A method and apparatus for hardware execution and acceleration of object-oriented instructions in object-oriented run-time systems is provided.

Description

Svstem Registers for an Object-Oriented Processor

Related Applications

This application claims priority and is related to commonly assigned PCT Application S.N. Docket number 1065PCT, filed herewith concurrently; US Patent Application S.N. 09/941,619 Docket Number 1078US; US Provisional Application S.N. 60/252,170 Docket Number 1065; US Provisional Application S.N. 60/276,375 Docket Number 1065.1; US Provisional Application S.N. 60/256,550 Docket Number 1089; and US Provisional Application S.N Docket Number 1034; which are all incorporated herein by reference. Field of the Invention

The present invention generally relates to the execution of object-oriented instructions in object-oriented run-time systems, more particularly to methods and apparatuses for hardware execution or acceleration of object-oriented instructions in object-oriented run-time systems. Background

Mobile devices, such as cellular phones, are quickly becoming commodities, forcing manufacturers and designers of these devices to battle for market share in a price war, and squeezing profit margins. Accordingly, many have identified the need to enhance these devices with additional, meaningful capability by enabling the devices with Java™ or Javalike processing capability. These enhanced devices, combined with wireless high data transfer rate capability, provided by emerging 3G wireless technologies, will be central to enabling the vision of so-called "ubiquitous" computing. The Java platform promises better security for transactions, permits users to download new applications including video games, and promises a wealth of interactive content including streaming audio and video.

Traditional software Java Virtual Machines (JVM), which interpret Java bytecode into the machine language of a given computing platform, are slow. To obtain satisfactory performance of a software JNM on a standard embedded processor, the clock rate must be increased. Unfortunately, with the prior art the performance is achieved at the expense of high power consumption due to the increased clock rate. Additional memory is required to store the software implementing the software JNM, which additionally increases power consumption, size and cost of the mobile device. Others propose the use of just-in-time compilers (JIT), hardware accelerators, or mere extensions to an existing processor's architecture. However, the most promising Java- enabling technology, by far, is the provision of a Java Native Processor into a mobile device.

Unfortunately, prior art Java Native Processors, such as the pico Java™ II designed by Sun Microsystems, Inc., Palo Alto, California, have yet to be incorporated in a consumer device. One of the shortcomings of prior art Java Native Processors is their high power consumption. Another shortcoming was their large size.

The Java run-time environments, and other object-oriented run-time environments, generally comprise an assortment of data structures for representing classes, objects, etc., the details of which generally vary from implementation to implementation. For example, the JNM specifications (e.g. J2ME (KNM), J2SE, J2EE, etc..) specify general, abstract data structures that must be present to comply with the standard and guarantee compatibility with Java code, while the same specification may specify that certain information must be available in the run-time system, without specifying the exact structure of the data structure(s) provided for that purpose.

A typical JNM runtime environment may include a set of loaded classes, a heap for storing objects data structures, and one or more stacks for maintaining method call chains.

A class loader may also be included, the class loader, among other things, parses class files, loading them into the JNM runtime environment.

Bytecode contained in class files provide executable bytecode, or instruction bytecode in any methods specified therein as well as information bytecodes for the linking of the class into the run-time system as well as other purposes.

Each class may also include a "constant pool" to support dynamic linking. The constant pool comprises such information bytecodes, describing linkages between the class and other classes, methods, objects, fields, etc... with which the class interacts. Many object-oriented instructions, for instance JNM instructions, may include an index into a class's constant pool. Thus, a hardware implementation of an object-oriented system may be required to interact with the constant pool as well as other run-time data structures such as class data structures and object instance data structures.

The prior art teaches a Java processor, the picoJava II processor, which substitutes symbolic constant pool references with numeric constant pool references, and wherein the numeric references comprise actual data or references combined with the use of a constant pool pointer register which holds a pointer to the constant pool of the current method's class.

Disadvantageously, the substitution of constant pool entries requires a significant amount of processing as well as toggling of memory circuits, the latter generally known to contribute an increase in power consumption. Additionally, access to a method for exception handling may be inefficient.

Accordingly, certain hardware object-oriented systems, such as hardware JVM implementations, may need to efficiently access constant pools, locate classes, methods, and the like, to further increase performance over other hardware object-oriented systems and their slower software counterparts. Summary of the Invention

One embodiment of the invention includes a processor for executing object-oriented instructions, the processor comprising: a memory comprising a class table data structure, a class data structure, and a method data structure; a class table register adapted to point to the class table; a current method value adapted to identify the method data structure associated with the method currently being executed by the processor; and a current class value to identify the class data structure of the class associated with the current method. The processor may further comprise a Current Class / Current Method (CC/CM) register containing both the current class value and the current method value. The processor may comprise a CC/CM register comprising a first part of the CC/CM register for storing the current class value and a second part of the CC/CM register storing the current method value. The processor may further comprise one or more object-oriented instructions for accessing the data structures, the instructions adapted to use the class table register, the current class value, and the current method value. The processor may further comprise: a stack data structure stored in the memory, the stack for holding method frames, the method frames containing a context; the processor comprising one or more context switch instructions, the processor adapted to execute the one or more context switching instructions, at least one of the context switching instructions for switching from a current context to a new context, adapted to build a new method frame on the stack and store the current context in the context of the new method frame, and at least one of the context switching instructions for switching instructions for switching from a current context to an old context, adapted to restore the old context from the context of a method frame on the stack. The context switching instructions for switching to a new context may comprise a method invocation instruction, and at least one of the context switching instructions for switching instructions for switching to an old context comprises a return instruction.

One embodiment of the invention includes a system for executing one or more object- oriented instructions, the system comprising: a memory containing one or more data structures; and a class data structure stored in the memory, the class data structure comprising a first portion for storing class information that is not required to be altered at run-time, and a the second portion for storing modifiable class information, wherein the first portion may be stored in read-only memory, and object-oriented operations may be conducted on information in the first portion at run-time, while the second portion may be stored in volatile memory at run-time, and object-oriented operations may be condcuted on the information in the second portion. In one embodiment, the first portion comprises a class data structure, and the second portion comprises a separate modifiable class data structure.

One embodiment of the invention includes a system for executing object-oriented instructions comprising: a processor having at least one object-oriented instruction in its instruction set; a memory operatively coupled to the processor; a system class table for holding a system class table, the system class table residing in the memory, the system class table comprising references to a plurality of classes; a class table register for holding a reference to the system class table; a current class register for holding a class table index value representing a current class; and a current method register for identifying the method in which the system is operating. The system may also include the current class, current method, and class table memories being located in the processor. The system may also include, the current class, current method, and class table memories comprising registers. The system may also include the current class memory and current method memory comprising a single register. The system may be selected from the group comprising: a hardware Java system, a Java processor, or a Java accelerator.

One embodiment of the invention includes a hardware Java apparatus comprising: a class table for identifying a plurality of classes loaded in the apparatus; a class table register for holding the base address of the class table; a current class register for holding a class index into the class table, the class index identifying an operating class; and a current method register for identifying an operating method within the operating class.

One embodiment of the invention includes a processor for executing object-oriented instructions, the processor comprising: a memory comprising a class table data structure, a class data structure, a modifiable class data structure, and a method data structure; a class table register adapted to point to the class table; a current method value adapted to identify the method data structure associated with the method currently being executed by the processor; and a current class value to identify the class data structure and modifiable class data structure of the class associated with the current method. The processor may further comprise a CC/CM register containing both the current class value and the current method value. The processor may contain a CC/CM register comprising a first part of the CC/CM register for storing the current class value and a second part of the CC/CM register storing the current method value. The processor may also include a class data structure comprising class information that is not required to be altered by the processor at run-time, and wherein the modifiable class data structure comprises class information that must be alterable by the processor at run-time. The processor may also include one or more class files that are pre- processed, the one or more classes files each having a pre-processed class data structure and a pre-processed modifiable class data structure. The processor may further comprise a readonly memory and a volatile memory, the pre-processed class data structures stored in the read-only memory, and the pre-processed static data structures stored in the volatile memory. The processor class data structures for the one or more pre-processed classes and the modifiable class data structures for the one or more pre-processed classes may be stored in read-only memory, and the processor further comprising a system initialization routine adapted to copy the one or more modifiable class data structures to the volatile memory.

One embodiment of the invention includes a class file pre-processing tool adapted to generate one or more pre-processed class files, to generate a class data structure for pre- processed classes and a modifiable class data structure for pre-processed classes, the class data structure comprising class information that is not required to be altered by the processor at run-time, the modifiable class data structure comprising class information that must be alterable at run-time.

One object of the present invention is to provide methods and systems to permit an object-oriented processor to efficiently access object-oriented data structures and perform object-oriented operations upon classes, methods, constant pools, fields, etc....

Further aspects and benefits of the present invention, as described herein will be apparent to one skilled in the art. Finding the class data structures through the constant pool may require significant processing upon class loading and may require the replication of method data structures for inherited methods.

Embodiments of the present invention may provide rapid access to the method for exception handling; rapid access to the class for static method invocations; rapid access to the class's static data for static data operations such as getstatic and putstatic.

Description of Drawings

Figure 1. illustrates a block diagram of an object-oriented processor core that uses a constant pool register for performing object-oriented operations;

Figure 2. illustrates a typical run-time system for an object-oriented system;

Figure 3. illustrates a block diagram of an object-oriented processor core in accordance with an embodiment of the present invention;

Figure 4. illustrates the class table register and CC/CM register used to identify a current class;

Figure 5-1. illustrates a class table data structure and a detailed example of a class data structure;

Figure 5-2. illustrates details of a class information header of a class data structure;

Figure 6-1. illustrates the CC/CM register used to identify a current method;

Figure 6-2. illustrates details of a method entry pointer table in relation to a class inheritance structure;

Figure 7-1. illustrates a memory map of a run-time stack, the composition of method frame on the run-time stack, and elements of the return execution context segment of a method frame;

Figure 7-2. illustrates an embodiment of an object data structure;

Figure 8-1. illustrates details of a method entry data structure and a method handlers table associated therewith;

Figure 8-2. illustrates details of a method handlers table;

Figure 9-1. illustrates details of a field entry pointer table in a class inheritance structure;

Figure 9-2. illustrates details of field data structure;

Figure 10. illustrates a class table and a modifiable class data structure. Description

Figure 1 illustrates a conventional Java native processor core that may execute Java bytecode. Processor core 100 comprises a pre-fetch unit (PFU) 101, microsequencer unit (MSU) 102 having a microcode memory 110, and an instruction execution unit (IEU) 103 having a register file 120. Processor core 100 is coupled to system memory 130, which contains one or more class files.

System memory 130 is provided to class files as well as run-time data structures 165 such as run-time stack 140 (not shown). Run-time stack 140 is generally utilized for maintaining a call chain of method frames 150 (aka activation records)(not shown), for passing parameters to methods (or functions), returning results to callers, and for holding temporary results, etc. Run-time stacks are well known to those skilled in the art.

Register file 120 may comprise a plurality of specific purpose registers, including a status flag (Flags) register 121 for indicating various conditions during execution; local variable pointer (LP) 122, for pointing the local variables of the current execution context; frame pointer (FP) 123, for pointing to the return execution context; stack pointer (SP) 124, for pointing to top of the stack (TOS)140 in system memory 130; stack limit pointer (SL) 125, for pointing to the end of the current stack 140; program counter (PC) 126, for pointing to the next instruction to be fetched, and constant pool register 160, for pointing to the constant pool of the class associated with the current method.

Pre-fetch unit 101 fetches instructions from programs or method bytecode (not shown) in system memory 130 according to a value contained in program counter (PC) 126 register, or according to an instruction pre-fetch pointer stored in another register (not shown).

Microcode memory 110 receives a microprogram address 111 from PFU 101, corresponding to an opcode to be executed, to obtain one or more microinstructions comprising the microprogram that implements the opcode. The microinstructions are dispatched to IEU 103 to control the datapath and effect execution of the opcode.

Referring to Figure 2, an example of a JVM run-time system 165 and a few of its data structures are illustrated.

JNM run-time system 165, stored in memory 130, may include a class table 200, class data structures 210, method data structures 220, field data structures 230, run-time stacks 240, and object data structures 250. Other data structures may be provided such as interface data structures, a global string pool data structure, or other data structures which may be required by an object-oriented run-time system.

Class table 200 contains references to loaded classes. A class loader may insert new class references to the class table 200 as new classes are loaded. Each class reference may point to a class data structure 210.

Each class loaded by the system may be represented by a class data structure 210. Class data structure 210 maintains information related to its class such as the name of a super class, if the class files indicates inheritance from another class as well as the class's methods, fields, and interfaces. Class data structure 210 also includes the constant pool data structure(s) derived from the class file. Alternatively, class data structure may contain a reference to a constant pool data structure. Any methods associated with a class may be provided in a method data structure 220. The method data structure 220 may be accessed from the class data structure 210. The class data structure 210 may include references to multiple method data structures 220 where each method data structure 220 is associated with a single method. Alternatively, class data structure 210 may hold a reference to a data structure containing multiple references to the method data structures 220.

Method data structures 220, which may also be known as method entries, may contain the executable instruction bytecode of the method, the name of the method (provided as a string and/or as a hash key into a global string pool) as well as information derived from the class file, such as access flags, the maximum stack size of the method frame, the number of arguments, the number of local variables, etc...

Field data structures 230, which may also be known as field entries, may also be accessed from the class data structure 210, the field data structures containing information such as the name of the field (provided as a string and/or hash key into a global string pool), a reference to the class defining the type of the field, access flags, etc...

Each thread in the JNM may be associated with a run-time stack 240. Stack 240 stores "stack frames" (or method frames), each comprising the execution context and related data of a single method invocation or function call. As a thread develops a call chain of methods at run-time, method frames are pushed on to the thread's stack 240. A local variable segment of method frames frequently contains a reference to the object that invoked the method associated with the frame. Thus, stack 240 may contain one or more references to object data structures 250. Object data structures 250 exist for every object instantiated in the JVM system. In one embodiment, multiple threads may share object data structures 250.

Object data structures 250 may contain a reference to the class data structure representing the class of the object, a monitor or pointer to a monitor to provide threads with mutual exclusion on the object, data fields associated with the object, or other information.

In one embodiment, class data structure 210 may include within itself method data structure 220 and/or field data structure 230, wherein pointers to method data structures 220 and field data structures 230 comprise internal pointers to locations within class data structure 210 containing the respective method data structure 220 or field data structure 230.

Referring now to Figure 3, an object-oriented processor core 300. Object-oriented processor core 300 may generally comprise a similar design as processor core 100, with the exception of constant pool register 160 not being provided in processor core 300. Additionally, processor core 300 includes a class table (CT) register 305 to point to class table 200 in the JVM run-time system 165. The pointer held in class table register 305 may be initialized at system start-up. A current class / current method (CC/CM) register 310 is also provided in processor core 300. CC/CM register 310 may hold a value to identify a class table entry and a value to identify a method data structure 220. In one embodiment, the value identifying a class table entry is a current class index into class table 200, the current class being the class associated with the currently executing method.

The benefits of this approach will become apparent in the description of the invention that follows.

It should be understood that other embodiments may include two separate registers instead of the one CC/CM register 310 - one register containing the current class, and the second register containing the current method. Such embodiments are considered to be within the scope of the present invention, as described and cliamed herein. Those skilled in the art may adapt the teachings herein described to put such embodiments to practice. The embodiments that follow embody aspects of the present invention in the context of a single CC/CM register.

Referring to Figure 4, the class data structure 210 associated with the current class may be accessed by generating an address into memory 130 by applying current class index to the contents of the class table register 305. Accessing the contents of this address in memory 130 will provide a class pointer to the class data structure 210. Elements contained in class data structure 210 may be accessed by applying pre-determined offset values. In this way, information contained in and available through class data structure 210 may be accessed, including the constant pool 215.

Referring to Figure 5-1, an example of a class data structure 210 is shown, linked to the instruction set of object-oriented processor through CT register 305, CC/CM register 310 and class table 200. Class data structure 210 includes a class information header 501 which may be of known size. Figure 5-2 illustrates elements that may be contained in class information header 501. In particular, class information header 501 may include constant pool pointer 502, to locate the constant pool of the class. Alternatively, the constant pool of each class may be stored externally to class data structure 210 with constant pool pointer 502 pointing to the external location comprising the constant pool. Class data structure 210 as illustrated includes a method entries pointer table 500, which comprises a array of method pointers, each pointing to a method data structure 220. In the illustrated embodiment, array of pointers 500 is located adjacent to class information header 500, which may be of a known, pre-determined size. Thus the array of pointers 500 may be easily found by applying an offset corresponding to the known, pre-determined size. In one embodiment this offset may be available in an address calculation unit in IEU 103. Class data structure 210 may also comprise an interface pointer table 503; for pointing to interface data structures associated with the class; a field entries pointer table 504, for pointing to field data structures associated with the class; and any other structures required to support run-time object- oriented operation upon the class.

The value contained in CC/CM register 310 to identify a method data structure may comprise an index into a list of pointers to one or more method data structures 220 associated with the current method. Figure 6-1 illustrates how the current method value may be used to access the method data structure 220 of the current method. Class data structure 210 of the current class may first be found (as described above), and the current method index may be applied to the class data structure 210. In the illustrated embodiment, the method entry pointer table 500 to method data structures may be located at a fixed location (e.g. a known, predetermined offset for the base of the class data structure) within class data structures 210. In the illustrated embodiment, method entry pointer table 500 is located adjacent to class information header 501, the latter having a known size. In an alternative embodiment, class data structures 210 may include an internal pointer to an array of one or more pointers to method data structures contained in the class data structure. In yet another embodiment class data structures contain a pointer to an intermediate data structure containing pointers to one or more method data structures. In any event, the current method index may be applied to an array of pointers to method data structures 220, to identify and provide access to the method data structure 220 associated with the currently executing method.

Referring to Figure 6-2, the class data structure 210- A of a class, the class data structure 210-B of the class's super class, and the class data structure 210-C of the super class's super class are shown. For example, Class A may inherit from Class B, which in turn inherits from Class C. Class data structure 210-A contains a method entry pointer table 500- A with method pointers to 'N' methods, where 'N' represents some integer value. Method entry pointer table 500- A in class data structure 210-A of Figure 6-1 is expanded to show the multiple pointers to the method data structures 220 of each method associated with the class. Each class data structure 210 may contain method data structures 220, as illustrated. Alternatively, method data structures 220 may be located externally to the class data structures 210, for instance in a method area of memory 130. Class data structure 210-A contains "method 0" and "method 1", inherited from Class C through Class B; "method 2" and "method N", comprising new or overridden methods in Class A; "method 3", inherited from Class B; and where N > 4, other methods between 4 to (N-l) (not shown). Accordingly, method entry pointer table 500-A includes "method 0" pointer and "method 1" pointer, both pointing to their respective method data structures 220-0 and 220-1 in class data structure 210-C; "method 2" pointer and "method N" pointer, pointing to their respective method data structures 220-2 and 220-N in class data structure 220- A; and "method 3" pointer, pointing to method data structure 220-3 in class data structure 220-B. In this way, object-oriented methods, including those provided through a class inheritance scheme, may be accessed by instructions executed in object-oriented processor core 300.

Threads executing on object-oriented processor core 300 may create a call chain of method invocations, causing the execution context thereof to change as method invocation and return instructions are executed thereon. Accordingly, a history of execution contexts may be persevered to restore the proper execution context upon the execution of a return instruction or the like. Stack 140 of each thread may include multiple method frames 150 as a call chain is developed. The method frame 150 of the current method may be identified by one or more pointers. Referring to Figure 7-1, a local variable pointer 122, frame pointer 123, and a stack pointer 124 may point into the method frame 150 associated with the current method. Additionally, a stack limit pointer 125 may be maintained to indicate the end of allocated memory in memory 130 provided for stack 140. In one embodiment any or all of pointers local variable pointer 122, frame pointer 123, stack pointer 124, and stack limit pointer 125 may be maintain in dedicated registers in object-oriented processor 300.

Generally, the exact structure of the method frames 150 are defined by the nature of the system architecture, and the data required to reinstate the execution context on processor core 300.

In the example illustrated in Figure 7-1, method frame 150 comprises three method frame segments: local variable segment 151, "return execution context" segment 152, and local stack operand segment 153.

Local variable segment 151 may comprise local variables required for the execution of the method. Local variable segment 151 may also include any parameters passed to the method by its caller. If parameters are passed to a method from its caller, the caller will first push the parameters onto its local operand stack segment 153 in stack memory 140. When the caller invokes a Java method, an invoke instruction is executed. The invoke instruction may include construction of a new Java frame 150 for the invoked method on stack memory 140, such that new Java frame 150 overlaps with any parameters in the local stack operand segment 153 in the caller's method frame. Accordingly, the invoked Java method may access the parameters as local variables.

The return execution context segment 152 typically contains the information required to restore the execution context of the caller when the method returns program control thereto (i.e. upon the execution of a return instruction). Typically, execution context segment 152 will include a plurality of elements, including a return program counter (PC) 1522, return frame pointer (FP) 1524, return local variable pointer (LP) 1523, and a return CC/CM value 1521 containing both the current class index and the current method index.

The return execution context segment 152 may be constructed by pushing each of its elements onto stack memory 140.

Local stack operand segment 153 is defined in Java frame 150 to accommodate temporary results and to pass parameters to methods and receive return values from methods invoked by the method associated with the current context. In Java environments, these temporary operands are known as local operands, stack operands, or local stack operands. Local stack operands may comprise constants, for example, local variables, fields, references, results, etc. As processor core 300 executes instructions of a method, local stack operand segment 153 may grow and shrink as certain instructions, such as the JNM opcodes i_const0, aload, astore, and the like, push and pop local stack operands onto stack memory 140. For example, the JNM iadd instruction pops the top two elements off local operand stack segment 153, adds the two elements in an ALU in processor 100 and generates a sum, and pushes the sum onto the local operand segment 153 (i.e.: the top of stack). The sum may be subsequently stored in a local variable, serve as an operand to a subsequent instruction, or be returned to the caller as a return value. Stack pointer 124 indicates the location of the top element (TOS) of the local stack operand. Memory locations beyond stack pointer 124 contain invalid data.

Thus, as a return instruction executes, the return routine may pop the return CC/CM value 1521 from the current method frame 150, writing the value to CC/CM register 310. Method invocation routines may push the contents of the CC/CM register 310 onto stack 140 when building a return execution context segment 152 on the stack 140. Method invocation routines may then update the content of the CC/CM register 310 with the correct value for the invoked method.

In multi-threaded systems, a return CC/CM value 1521 may be preserved when a thread is moved out of the running state to another non-running state. In one embodiment, the return CC/CM value may be pushed onto its own stack for reinstatement upon the thread returning to the running state.

Class table register 305 and CC/CM register 310 may be utilized by various operations executed in object-oriented processor 300. Such operations may involve the accessing of various run-time data structures including class data structures 210, method data structures 220, field data structures 230, object data structures 250, interface data structures (not illustrated), and the like.

Referring to Figure 7-2, an exemplary embodiment of object data structure 250 is shown. Object data structure 250 may include an object class pointer 2501 for pointing to the class data structure 210 of the class from which the object was instantiated; a monitor 2502 (or pointer to a monitor) for permitting mutual exclusion upon the object by a thread; and any data fields 2503 associated with the object, the data field 2503 comprising data or references to object data structure comprising a field. Other embodiments may represent objects using a different object data structure formats without departing from the scope of the present invention as claimed herein. Object data structure 250 may be accessed as a local variable comprising a reference to the object, the local variable in local variable segment 151 on a stack 140; as a stack operand in the stack operand segment 153 on a stack 140; as a field

2503 of another object; or as a static field of a class (not shown). A detailed embodiment of an exemplary method data structure 220 is provided in Figure 8-1. A method entry pointer table 500 in a class data structure 210 contains 'N' method pointers, where 'N' is an integer value. "Method 1" pointer in table 500 points to method data structure 220-1. Method data structure 220-1 includes a method information header which is of a fixed, pre-determined size, followed by a bytecode array 805 comprising executable instruction bytecode of the method. For object-oriented processor 300 to handle exceptions which may be thrown during the execution of a method, object-oriented processor 300 may need to access one or more method handlers. Thus, the method information header of method data structure 220-1 may include a method handlers table pointer 800 to method handlers table 810. Method handlers table 810 contains method handler data structures 815 for each of the method handlers that may be required by a method. Figure 8-2 illustrates details of an exemplary method handler data structure 815X in method handler table 81 OX, associated with a method

X in some class. Each method handler may also be associated with executable instruction bytecode, provided for the execution of the method handler, which may be included in bytecode array 805 of the method, for instance at the end of the bytecode array 805. Method handlers and exception handling by object-oriented processor 300 will be discussed further below.

Referring now to Figures 9-1 and 9-2, details of a field data structure 230 of an exemplary embodiment are shown. Class data structure 210 includes a field entry pointer table 504, containing field pointers to the field data structures 230 of the fields associated with the class. In an object-oriented system, a given class may inherit fields from an inheritance tree of other classes. Referring to Figure 9-2, the class data structure 210-A of a class, the class data structure 210-B of the class's super class, and the class data structure

210-C of the super class's super class are shown. This could correspond to Class A inheriting fields from Class B, which in turn may inherit fields from Class C. Class data structure 210-A contains a field entry pointer table 504 comprising an array of pointers to 'N' field data structures 230, where 'N' represents some integer value. Field entry pointer table 504 A in Figure 9-1 is expanded to show the multiple pointers to each field contained therein.

Each class data structure 210 may contain field data structures 230, as illustrated.

Alternatively, field data structures 230 may be located externally to the class data structures

210, for instance in a field area of memory 130. Class data structure 210-A contains "field

0" and "field 1", inherited from Class C through Class B; "field 3" and "field N" comprising new fields in Class A; "field 2", inherited from Class B; and where N > 4, other fields between 4 to -(N-l) (not shown). Accordingly, field entry pointer table 504-A includes

"field 0" pointer and "field 1" pointer, both pointing to their respective field data structures

230-0 and 230-1 in class data structure 210-C; "field 3" pointer and "field N" pointer, pointing to their respective field data structures 230-2 and 230-N in class data structure 210-

A; and "field 2" pointer, pointing to field data structure 230-3 in class data structure 210-B.

In this way fields, including those provided through a class inheritance scheme, may be accessed by instructions executed in object-oriented processor core 300.

An exemplary embodiment of a field data structure 230 is illustrated in Figure 9-2. A field entry pointer table 504 includes N fields, where N is an integer value, is shown in Figure 9-2. "Field 1" pointer, points to field data structure 230-1, illustrated in detail. Elements of the field data structure 230-1 may be utilized by various object-oriented operations by object-oriented processor 300, described further below.

Figure 10 illustrates an embodiment wherein class information and data that must remain modifiable by object-oriented processor 300 at run-time, is maintained in a modifiable class data structure 1000. Modifiable Class data structure 1000 may contain class information that must remain modifiable at run-time, such as the class's static fields and a monitor or pointer to a monitor associated with the class (as opposed to a particular object, or instance, of the class). Other embodiments may include other class information or data may be included in modifiable class data structure 1000. Modifiable Class data structure 1000 contains a pointer to the class data structure 210. Modifiable Class data structure 1000 may be accessed through a class table 1020. Class table 1020 contains two references for every loaded class: the class pointer, pointing to the class data structure 210 of the class; and modifiable class pointer 1010, pointing to the modifiable class data structure 1000 of the class. An advantage of this embodiment is that the information required for a class is split into two sections: a class data structure 210 which contains information that is not required to be altered by object-oriented processor 300 during run-time, and a modifiable class data structure 1000 which contains information that must be alterable at run-time by object- oriented processor 300. In this way, classes that are pre-loaded by a pre-processing tool, such as a ROMizer, may be implemented with a substantial portion of its class information loaded into read-only memory (ROM) at run-time. This may reduce the amount of volatile memory (random access memory - RAM, for example) required by the system as the class data structures 210 of the pre-loaded classes may remain in read-only memory at run-time, while modifiable class data structure 1000 may be pre-processed and stored in ROM, but copied to RAM at system start-up so as to permit alteration of its information. Accordingly, the class table entries for pre-loaded classes may comprise a class pointer pointing to the class data structure 210 stored in read-only memory, and a modifiable class pointer 1010 pointing to the modifiable class data structure 1000, located in memory such as RAM. In one embodiment, a class file pre-processing tool for an object-oriented processor, may pre- process one or more class files to be pre-loaded onto a read-only memory that may be coupled to object-oriented processor 300. In this embodiment, class pre-processing tool may build a class table 1020, class data structure 200 (including within it method data structures 220 and field data structures 230), and a modifiable class data structure 1000. Class table 1020 may contain class pointers to class data structures 210 of the pre-loaded classes, and modifiable class pointers 1010 to modifiable class data structures 1000 of the pre-loaded classes. The class table 1020, class data structure 210 of the pre-loaded classes, and the modifiable class data structures 1000 of the pre-loaded classes may then be stored in the read-only memory for later use. An object-oriented processor making use of the pre-loaded class may then copy the class table 1020 and the modifiable class data structures 1000 to locations in a volatile memory, the modifiable class pointers 1010 of the pre-loaded classes being updated to point to the locations in volatile memory. In one embodiment a bootstrap routine or other system initialization routine may perform the copy step and updating of modifiable class pointers 1010. In one embodiment, the pre-processing tool may create Unicode string objects referenced by constant pool entries tagged as CONSTANT_String entries in the constant pools 215 of the pre-loaded classes. The Unicode string objects may then be stored in locations in the read-only memory and the constant pool entries associated with the CONSTANT_String tags may reference to the Unicode string object in read-only memory. In one embodiments, the pre-processing tool may generate and copy to read-only memory, a global string pool for CONSTANTJLJTF8 constant pool entries, and other string data that may be used in run- time data structures 165. The pre-processing tool may build the global string pool, inserting all string data from CONSTANT_UTF8 constant pool entries and string data found in the run-time data structures 165 of the pre-loaded classes. Thus, the global string pool entries for this string data will be copied to read-only memory. Upon system initialization, the global string pool may be copied to volatile memory to permit further growth of the global string pool during run-time. Key references located in class data structures 210, method data structures 220, and field data structures 230 do not need to be changed with the copying of the string pool to volatile memory as the key values need not change. Alternatively, global string pool entries generate by the pre-processing tool for preloaded classes, may remain in read-only memory, while the global string pool structure (such as a hash table) that links to the entries is copied to volatile memory. Global string pool entries generated at run-time may then be inserted to the global string pool by updating links (pointers) within the pool such that any entries located in read-only memory comprise the last elements in a linked-list, within a hash-table or the like.

Certain JNM instructions make reference to constant pool entries to specify a method, class, field, or the like. For instance, constant pool references may be used by method invocation instructions, getfield and putfield instructions, etc.... Such instructions typically include an operand that is an index into the current class's constant pool. The index into the constant pool provides the instruction with a "hook" to access the desired method, class, field, or the like. Instructions need to "resolve" their constant pool references by accessing and sometimes recursing into the constant pool to obtain constant data or one or more string values, such as a key to identify an entry in a global string pool. These may then be used to find and identify the desired method, class, field, or the like, by comparing the string value(s) to strings stored in the various data structures representing methods, classes, fields, etc...

In class files, the constant pool contains self-referential entries and symbolic references in the form of strings. Each constant pool entry comprises a one-byte constant pool entry tag value to indicate one of many constant pool entry types, followed by one or more bytes of constant pool entry data, the constant pool entry data being type-specific

Constant pool tags and their meaning are known to those skilled in the art. The following constant pool tags may be found in the constant pool of class files:

COΝSTAΝT_UTF8; CONSTANT_String; CONSTANT nteger; CONSTANT_Float; CONSTANT_Long; CONSTANT_Double; CONSTANT_Class; CONSTANT_Fieldref; CONSTANT_Methodref; CONSTANT_InterfaceMethodref; CONSTANT_NameAndType; When a class is loaded into a JVM run-time system by a class loader, the loader may load constant pool entries into one or more data structures provided to maintain constant pool info. In other embodiments, the constant pool in a class file may be pre-loaded by a class pre-processing tool, such as a "ROMizer". In one embodiment, a constant pool array and a constant pool tag array are provided for maintaining constant pool info of a JVM run-time system. The constant pool of each loaded class may be stored in system memory 130, in one or more data structures as part of the run-time system 165. In one embodiment, the loaded constant pool of a class is stored in the class data structure 210. In one embodiment, a global string pool is maintained in a run-time system wherein constant pool entries containing string data may be stored in the global string pool. Strings stored in run-time data structures such as class, method, field and other data structures may also be stored in the global string pool.

Where a string value is stored in the global string pool, a key to the entry in the pool may be maintained where the string or strings would have been maintained. Embodiments using a global string pool in this way may conserve memory space by only storing a given string once regardless of the number of constant pool entries or run-time data structures that may make use of the given string. In one embodiment, the global string pool comprises a hash table. Accordingly, in embodiments utilizing a global string pool as described, a class loader may perform an insertion function to insert any strings in the constant pool entries contained in a class file being loaded, the loaded constant pool entries corresponding to strings comprising a key into the global string pool.

Several object-oriented operations to be performed by object-oriented processor 300 may require constant pool resolution of one or more items associated with a constant pool reference. Examples of such operations are described below. The examples provided below correspond to the embodiment illustrated in Figure 10, using class table 1020. Simple constant resolution

CONSTANTJnteger, CONSTANT Float, CONSTANT_Long, and

CONSTANTJDouble may be resolved by just being loaded into constant pool 215 as they may directly contain the data. In one embodiment CONSTANT_String can be resolved by substituting the CONSTANT_String entry found in the class file into a reference to a memory location where a Unicode string object is located, the string object represented by data structure. In one embodiment, the data structure representing a Unicode string object comprises a fixed length header, followed by Unicode-encoded string data. In one embodiment, the CONSTANT_String entry in constant pool 215 may be stored as a length value indicating the length of the string data, followed by the string data. This set of resolutions can be performed at load time.

Class resolution

In one embodiment, where a global string pool is utilized, a Class may be tested for presence by hashing a key located at the constant pool 215 entry at a CONSTANT_Class index into the global string pool. Class data structures 210 linked in the system Class Table 1020 may be searched to check a "Constant Pool Name and Key Reference", which may be stored in the class data structure 210 of each Class, to try and find a matching index. If a match is found, the class had already been loaded and the Class Pointer from the entry in the system Class Table 1020 is returned. If no match is found, then a class loader may load the class.

In the descriptions of various resolutions that follow, the various offsets correspond to offsets in the various class, method, and field data structures described above and illustrated in the Figures. Additionally, the descriptions that follow are related to an embodiment where each word in data structures and words on the stack comprise 32-bit (4 byte) words. It should be understood that aspects of the present invention are not limited to such specific embodiments, but the described embodiments serve only to illustrate broader aspects of the present invention. Getfield resolution:

A getfield instruction is encountered with the following state. The stack contains the object reference that is the target of the getfield. The bytecode for the getfield is followed by two operand bytes containing an index into the current class' constant pool 215 to a CONSTANT_Fieldref entry. The following steps may be used to resolve the getfield:

1. Use the Class table register 305 and Current Class index from the CC/CM register 310 to get the Class data structure 210. 2. Index into the Class data structure 210 to the Constant Pool Pointer 502 in

Class Information 501 to find the Constant Pool 215.

3. Locate the operand bytes to obtain the index into the constant pool array to locate the CONSTANTJFieldref entry.

4. Find the CONSTANT_Class from the CONSTANTJFieldref and resolve the Class (Possible Class not found exception thrown).

5. Find the CONST ANT j ameAndType from the CONSTANTJFieldref and resolve the Field (returns a Field Pointer).

6. If the Object Reference on the stack is Null, throw a Null Pointer Exception.

7. Pop the object reference off the stack.

8. If the field is a 64-bit field then use the Field Offset (stored in field data structure 230) * 4 + 12 (the 4 provided to scale the value to bytes, the 12 provided to skip 8 bytes comprising the class pointer and the monitor, stored in the object data structure 250, and to skip a further 4 bytes to access the lowest 32-bits of the 64-bit field) and offset into the referenced object to access the low 32-bits of the data and push it on the stack.

9. Use the Field Offset * 4 + 8 and offset into the referenced object to access the 32 bits of data and push it on the stack.

10. <End ofGetfield> Putfield resolution:

A putfield instruction is encountered with the following state. The stack contains one or two words of data and the object reference that is the target of the putfield. The byte code for the putfield is followed by two operand bytes containing an index into the current class' constant pool to the Fieldref entry. The following steps may be used to resolve the putfield:

1. Use the Class table register 305 and the Current Class index from the CC/CM register 310 to get the Class data structure 210.

2. Index into the Class data structure 210 to the Constant Pool Pointer 502 in Class Information 501 to find the Constant Pool 215.

3. Locate the operand bytes to obtain the index into the constant pool array to locate the CONSTANT Fieldref entry.

4. Find the CONSTANT_Class from the CONSTANT Fieldref and resolve the Class (Possible Class not found exception thrown). 5. Find the CONSTANT_NameAndType from the CONSTANTJFieldref and resolve the Field (returns a Field Pointer).

6. If the Object Reference on the stack is Null, throw a Null Pointer Exception (the offset of the Object Reference into the stack is known from the size of the data as derived from the type string).

7. If the field is a 64-bit field then pop the data off the stack into a register labeled herein as 'tempHigh'.

8. Pop the data off the stack into a register labeled herein as 'tempLow' .

9. Pop the obj ect reference off the stack.

10. If the field is a 64-bit field then use the Field Offset * 4 + 12 and offset into the referenced object to write the contents of 'tempLow'.

11. If the field is a 64-bit field then use the Field Offset * 4 + 8 and offset into the referenced object to write the contents of 'tempHigh'.

12. If the field is a 32-bit field then use the Field Offset * 4 + 8 and offset into the referenced object to write the contents of 'tempLow'.

13. <end of ρutfield> Getstatic resolution:

A getstatic is encountered with the following state. The stack contains no data for the getstatic. The byte code for the getstatic is followed by two operand bytes containing an index into the current class' constant pool to the Fieldref entry. The following steps may be used to resolve the getstatic:

4. Find the CONSTANT_Class from the CONSTANT_Fieldref and resolve the Class (Possible Class not found exception thrown).

5. Find the CONSTANT_NameAndType from the CONSTANT_Fieldref and resolve the Field (returns a Static Field Pointer).

6. Index into the class table 200 by the class's class table offset (stored in the class object data structure 210) * 8 + 4 to get the modifiable Class pointer 1010.

7. If the field is a 64-bit field then use the Field Offset * 4 + 12 and offset into the class static data structure 1000 to access the low 32-bits of the data and push it on the stack.

8. Use the Field Offset * 4 + 8 and offset into the class static data structure to access the 32 bits of data and push it on the stack.

9. <end of getstatic> Putstatic resolution:

A putstatic is encountered with the following state. The stack contains one or two words of data for the putstatic. The byte code for the putstatic is followed by two operand bytes containing an index into the current class' constant pool to the Fieldref entry. The following steps may be used to resolve the getstatic:

1. Use the Class table register 305 and the Current Class index from the CC/CM register to get the Class data structure 210.

3. Locate the operand bytes to obtain the index into the constant pool array to locate the CONSTANT_Fieldref entry.

4. Find the CONSTANT_Class from the CONSTANT Fieldref and resolve the Class (Possible Class not found exception thrown).

6. Use the Class Offset * 8 + 4 to get the Class static pointer 1010.

7. Pop 32 bits of data off the stack and use the Field Offset * 4 + 8 and offset into the class static data structure 1000 to write the data.

8. If the field is a 64-bit field then pop 32 bits of data off the stack and use the Field Offset * 4 + 12 and offset into the class static data structure 1000 to write the data.

9. <end of putstatic> Invokevirtual resolution:

An invokevirtual is encountered with the following state. The stack contains the object reference that is the target of the virtual invocation and the set of calling parameters.

The byte code for the invokevirtual is followed by two operand bytes containing an index into the current class' constant pool to the CONSTANTJVIethodref entry. The following steps may be used to resolve the invocation:

3. Locate the operand bytes to obtain the index into the constant pool array to locate the CONSTANT_Methodref entry.

4. Find the CONSTANT__Class from the CONSTANTJVIethodref and resolve the Class (Possible Class Loader call and possible Class not found exception thrown, returns a Class Pointer).

5. Find the CONSTANT_NameAndType from the CONSTANTJVIethodref and resolve the Method (returns a Method Pointer).

6. Use the Method Pointer to get the Scaled Argument Count (stored in method data structure 220).

7. Use the Scaled Argument Count with SP 124 to locate the Object Reference on the stack 240.

8. If the Obj ect Reference is Null, throw a Null Pointer Exception.

9. If the Method Entry Access Flags (in method data structure 220) indicate a synchronous method then perform the following subsequence: a. If the Object Monitor Pointer is Null, allocate a monitor to the Object. b. If the Monitor Depth is greater than 0, block the thread on this monitor. c Set the Monitor Depth to 1 (Assume unblocked from above), d. Set Monitor Owner to the Class Table Current Thread (available in class table information header).

10. Use the object data structure 250 of the Object Reference to get the Class Pointer to locate the Class.

11. Use the Method Pointer Table Pointer and offset into the method pointer table by the resolved Method's Method Table Offset to get the correct virtual Method in this Class.

12. If the Method Pointer in the Method Table is Null, an AbstractMethodError is thrown.

13. If SP 124 - the virtual Method's Invoke Count is less than the contents of the Stack Limit register 125 then allocate a new stack chunk and decide where to split the stack. Throw a Stack Overflow Error if unable to allocate more stack.

14. Save LP 122 to a temporary location.

15. Set the LP 122 to SP 124 + virtual Method's Scaled Argument Count (stored in the method data structure 220).

16. Set SP 124 to LP 122 - virtual Method's Scaled Local Variable Count (stored in the method data structure 220).

17. Increment the PC by 3.

18. Push LP 122 + 4 onto the stack.

19. Push SL 125 onto the stack.

20. Push the saved LP onto the stack.

21. Push CC/CM register 310 onto the stack.

22. Push FP 123 onto the stack.

23. Push PC 126 onto the stack.

24. Set the CC/CM register 310 to the virtual Method's Class Table Offset/Method Table Offset.

25. Set the FP 123 to the current SP 124.

26. Set the PC 126 to point to the virtual Method's Byte Codes (beginning of bytecode array 805).

27. <End ofInvoke> Invokestatic resolution:

An invokestatic is encountered with the following state. The stack contains the set of calling parameters. The byte code for the invokestatic is followed by two operand bytes containing an index into the current class' constant pool to the Methodref entry. The following steps may be used to resolve the invocation:

1. Use the Current Class value stored in the CC/CM register 310 to get the Class data structure 220.

3. Locate the operand bytes to obtain the index into the constant pool array to locate the CONSTANTJVIethodref entry.

4. Find the CONSTANT_ Class from the CONSTANT_Methodref and resolve the Class (Possible Class Loader call and possible Class not found exception thrown, returns a Class Pointer). 5. Find the CONSTANT_NanιeAndType from the CONSTANTJVIethodref and resolve the Method (returns a Method Pointer).

6. If the Method Entry Access Flags (stored in method data structure 220) indicate a synchronous method then perform the following subsequence: a. If the Class Object Monitor Pointer is Null, allocate a monitor to the Object. b. If the Monitor Depth is greater than 0, block the thread on this monitor, c Set the Monitor Depth to 1 (Assume unblocked from above). d. Set Monitor Owner to the Class Table Current Thread.

7. If SP 124 - the virtual Method's Invoke Count (stored in method data structure 220) is less than the contents of the Stack Limit register 125 then allocate a new stack chunk and decide where to split the stack. Throw a Stack Overflow Error if unable to allocate more stack.

8. Save LP 122 to a temporary location.

9. Set LP 122 to SP 124 + static Method's Scaled Argument Count (stored in method data structure 220).

10. Set the SP 124 to LP 122 - static Method's Scaled Local Variable Count (stored in method data structure 220).

11. Increment PC 126 by 3.

12. Push LP 122 + 4 onto the stack 240.

13. Push SL 125 onto the stack 240.

18. Push the saved LP (from step 8) onto the stack 240.

19. Push CC/CM register 310 onto the stack 240.

20. Push FP 123 onto the stack 240.

21. Push PC 126 onto the stack 240.

22. Set the CC/CM register 310 to the static Method's Class Table Offset/Method Table Offset.

23. Set the FP 123 to the current SP 124.

24. Set the PC 126 to point to the static Method's Byte Codes (beginning of bytecode array 805).

25. <End of Invoke> Exception Processing

Exception processing involves several steps to locate the exception (method) handler and invoke the method handler bytecodes. The process may involve the following steps:

1. Determine which Class was executing when the exception was raised; a. This is identifiable from the Current Class value in the CC/CM register 310.

2. Determine which Method was executing when the exception was raised; a. This is identifiable from the Current Method value in the CC/CM register 310.

3. Access the method handlers table pointer 800 of the current method.

4. Check the method handlers available in this method to determine if the exception has a handler; a. This involves matching the resolved exception class of the handler (the Exception type field in the method handlers table) by comparing exception type field of the handler and the class of the resolved exception type thrown) with the resolved exception class in the exception source. Where the exception was caused by the execution of an athrow instruction, the stack entry pushed by the athrow instruction will require resolution.

5. Check the exception (method) handler 815 to determine if bytecode was executed inside the active range of the handler; a. Use the exception range start and exception range end fields of the method handler 815 to verify that PC 126 is in target range.

6. If the method handler is valid, set up the stack 240 to return to the handler. a. The absolute memory pointer can be found in the Method Handler 815, Bytecode Pointer entry.

7. If a method handler is not found, then pop the method frame 150 from stack 240 and look for a valid handler in the calling method.

8. If no handler is found, then the system may be shut down. The scope of the shut down could be just the thread, the application, or the whole NM. Typically, the NM is terminated with a console error message.

The steps for searching for an exception handler are well known in the art and are described on page 162 of Java Virtual Machine, by Jon Meyer and Troy Downing, Copyright 1997 by O'Reilly and Associates, hereby incorporated by reference.

Numerous modifications and variations of the present invention are possible in light of the above teachings. While aspects of the invention are discussed herein in the context of an object-oriented processor core, the aspects may also benefit object-oriented instruction hardware accelerators, such as Java technology-based instruction translation accelerators for translating Java bytecode into sequences of native instructions. Furthermore, while aspects of the present invention have been described herein in the context of a specific JVM run-time architecture, aspects of the present invention may be applied to various object-oriented technologies, and various JVM run-time architectures. Details of specific data structures and inter-relationships between various data structures, are provided only to illustrate broader aspects of the present invention.

It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Claims

1. A processor for executing object-oriented instructions, the processor comprising: a memory comprising a class table data structure, a class data structure, and a method data structure; a class table register adapted to point to the class table; a current method value adapted to identify the method data structure associated with the method currently being executed by the processor; a current class value to identify the class data structure of the class associated with the current method.

2. The processor according to Claim 1, further comprising a CC/CM register containing both the current class value and the current method value.

3. The processor according to Claim 2, wherein a first part of the CC/CM register for storing the current class value; a second part of the CC/CM register storing the current method value.

4. The processor according to Claim 1, wherein the processor further comprises one or more object-oriented instructions for accessing the data structures, the instructions adapted to use the class table register, the current class value, and the current method value.

5. The processor according to Claim 1, further comprising:

a stack data structure stored in the memory, the stack for holding method frames, the method frames containing a context;

the processor comprising one or more context switch instructions, the processor adapted to execute the one or more context switching instructions,

at least one of the context switching instructions for switching from a current context to a new context, adapted to build a new method frame on the stack and store the current context in the context of the new method frame, and

at least one of the context switching instructions for switching instructions for switching from a current context to an old context, adapted to restore the old context from the context of a method frame on the stack.

6. The processor according to Claim 8, wherein the at least one of the context switching instructions for switching to a new context comprises a method invocation instruction, and at least one of the context switching instructions for switching instructions for switching to an old context comprises a return instruction.

7. A system for executing one or more object-oriented instructions, the system comprising: a memory containing one or more data structures; a class data structure stored in the memory, the class data structure comprising a first portion for storing static data, the second portion for storing dynamic data.

8. A system for executing object-oriented instructions comprising: a processor having at least one object-oriented instruction in its instruction set; a memory operatively coupled to the processor; a system class table for holding a system class table, the system class table residing in the memory, the system class table comprising references to a plurality of classes; a class table register for holding a reference to the system class table; a current class register for holding a class table index value representing a current class; a current method register for identifying the method in which the system is operating.

9. The system according to Claim 8, wherein the current class, current method, and class table memories being located in the processor.

10. The system according to Claim 9, the current class, current method, and class table memories comprising registers.

11. The system according to Claim 9, the current class memory and current method memory comprising a single register.

12. The system according to claim 8, wherein the system is selected from the group comprising: a hardware Java system, a Java processor, or a Java accelerator.

13. A hardware Java apparatus comprising: a class table for identifying a plurality of classes loaded in the apparatus; a class table register for holding the base address of the class table; a current class register for holding a class index into the class table, the class index identifying an operating class; a current method register for identifying an operating method within the operating class.

14. A processor for executing object-oriented instructions, the processor comprising: a memory comprising a class table data structure, a class data structure, a class static data structure, and a method data structure; a class table register adapted to point to the class table; a current method value adapted to identify the method data structure associated with the method currently being executed by the processor; a current class value to identify the class data structure and class static data structure of the class associated with the current method.

15. The processor according to Claim 14, further comprising a CC/CM register containing both the current class value and the current method value.

16. The processor according to Claim 15, wherein a first part of the CC/CM register for storing the current class value; a second part of the CC/CM register storing the current method value.

17. The processor according to Claim 14, wherein the class data structure comprises class information that is not required to be altered by the processor at run-time, and wherein the modifiable class data structure comprises class information that must be alterable by the processor at run-time.

18. The processor according to Claim 17, wherein one or more class files are pre- processed, the one or more classes files each having a pre-processed class data structure and a pre-processed modifiable class data structure.

19. The processor according to Claim 18, the processor further comprising a read-only memory and a volatile memory, the pre-processed class data structures stored in the read-only memory, and the pre-processed modifiable class data structures stored in the volatile memory.

20. The processor according to Claim 19, wherein the class data structures for the one or more pre-processed classes and the modifiable class data structures for the one or more pre-processed classes are stored in read-only memory, and the processor further comprising a system initialization routine adapted to copy the one or more modifiable class data structures to the volatile memory.

21. A class file pre-processing tool adapted to generate one or more pre-processed class files, to generate a class data structure for pre-processed classes and a modifiable class data structure for pre-processed classes, the class data structure comprising class information that is not required to be altered by the processor at run-time, the modifiable class data structure comprising class information that must be alterable at run-time.