WO2002042898A2

WO2002042898A2 - Interpretation loop for object oriented processor

Info

Publication number: WO2002042898A2
Application number: PCT/US2001/043444
Authority: WO
Inventors: Guillaume Comeau; Thomas Bottomley; Vincent Deschenes; Michael Majid; Zohair Sahraoui
Original assignee: Zucotto Wireless, Inc.
Priority date: 2000-11-20
Filing date: 2001-11-20
Publication date: 2002-05-30
Also published as: WO2002042898A3

Abstract

A system and method are provided in which functionality provided by VMSS, SLSS, and IL domains is overlapped.

Description

Interpretation Loop for Object Oriented Processor

Related Applications

This application claims priority and is related to commonly assigned PCT Application S.N. Docket number 1123PCT, filed on this day concurrently; PCT Application S.N. Docket number 1024PCT, filed on this day concurrently;

PCT Application S.N. Docket number 1074PCT; filed on this day concurrently;

US Provisional Application S.N. 60/276,375 Docket Number 1065.1;

US Provisional Application S.N. 60/252,170 Docket Number 1065

US Provisional Application S.N. 60/323,022 Docket Number 1123 US Provisional Application S .N. 60/290,520 Docket Number 1024 1;

US Provisional Application S.N. 60/270,696 Docket Number 1024:

US Provisional Application S.N. 60/323,022 Docket Number 1034;

US Provisional Application S.N. 60/298,184 Docket Number 1038: and

US Provisional Application S.N. 60/256,550 Docket Number 1089; which are all incorporated herein by reference.

Field of the Invention

This invention generally relates to providing an overlap between various domains in a system. More particularly, this invention relates to providing one or more overlap between

NMSS, SLSS, and IL domains. Background

Referring to Figure 1, there is illustrated a representation of a Virtual Machine (NM), an operating system, and a hardware/processor layer.

The NM comprises code that is compiled to a supported virtual machine specification, after which it may be invoked by an operating system. Previously, the compiled NM operated above the operating system layer, which in turn operated above a hardware/processor layer.

Because there existed multiple levels of abstraction that an application would need to interact through, it was previously difficult to provide applications with a high performance path between an application layer to the hardware/processor layer. Although solutions exist to speed up the hardware/processor layer, such an approach requires higher power consumption and still does not provide the applications with optimal access to the hardware/processor layer.

What is needed, therefore, are improvements above and beyond those provided by previous solutions.

Summary In one embodiment, a system may comprise: a NMSS domain, the NMSS domain including one or more NMSS data structures; an SLSS domain, the SLSS domain including one or more SLSS data structures; and an IL domain, wherein the SLSS data structures and the NMSS data structures comprise functionality that overlaps in the LL domain; and one or more computer readable medium, wherein the NMSS and SLSS data structures are implemented by the computer readable medium and wherein the system interacts with the data structures via the computer readable medium. In the system the NMSS domain may comprise one or more NMSS specific registers; the SLSS domain may comprise one or more SLSS specific registers; and the IL domain may comprise one or more IL specific registers, wherein the overlap of the functionality in the IL domain is provided by a system access of one or more of the registers. The NMSS data structures may comprise data structures for supporting a JNM implementation. The NMSS data structures may comprise data structures selected from a group consisting of Current Java Thread, Monitors, and Threads data structures. The SLSS data structures may comprise a Memory Block data structure. The SLSS data structures may comprise a Hardware peripherals data structure. The SLSS data structures may be compiled with an appropriate compiler to instructions belonging to a native instruction set of the system. The IL domain may include one or more pointer, including one or more NMSS mode specific pointer and one or more SLSS mode specific pointer. The JL domain may include instruction fetch, decode, and execute functionality; and the JL domain may include one or more domain specific pointer. The one or more domain specific pointer may be embodied by the computer readable medium as software. The one or more domain specific pointer may be embodied by the computer readable medium as hardware. In one embodiment, the system may comprise a processor, wherein the NMSS data structures comprise data structures provided to support Java functionality, wherein the SLSS data structures comprise data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the system, and wherein the processor is operatively coupled with the computer readable medium so as to provide the functionality that overlaps in the IL domain to the system. The JL domain may be provided as a hardware implementation selected from the group consisting of microcode, hardwired logic, and a combination of microcode and hardwired logic. In one embodiment, a device may comprise: a NMSS domain, the NMSS domain including functionality provided by one or more NMSS data structures, the one or more NMSS data structures including a Current Thread, a Class Table, and a Monitors data structure; an SLSS domain, the SLSS domain including functionality provided by a Memory Block data structure; and an IL domain, the IL domain including functionality, wherein the functionality provided by the SLSS and NMSS data structures is compiled to the IL functionality. The NMSS data structures may comprise Java data structures. The device may comprise a processor, wherein the SLSS data structures comprise data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor. The IL functionality may comprise one or more pointers. The JL functionality may be embodied as one or more register. The IL functionality may be embodied as a Java Register data structure. The one or more registers may comprise one or more mode specific registers. The IL functionality may comprise a processor having an instruction set, the instruction set including a first instruction group of JNM instructions and a second instruction group comprising platform dependant instructions, the instruction set supporting the execution of a first set of JVM instructions in hardware, the processor trapping to NMSS functionality to support the execution of a second set of JNM instructions with a sequence of one or more platform dependant instructions.

In one embodiment, a method of overlapping functionality may comprise the steps of: providing a set of mode specific registers; providing one or more data structures; and linking the data structures to the mode specific registers using a class loader. In one embodiment, the class loader supports data structures implemented for supporting instructions of a JVM implementation. In the method the mode specific registers may comprise Java registers and C registers. The one or more data structures may include Current Java Thread, Class Table, Monitors, Threads, Class Structure, C Frame, Memory Block, and HW Peripherals data structures.

In one embodiment, a processor based system may comprise: a VMSS domain operatively coupled to the processor and including one or more VMSS specific registers and one or more VMSS data structures implemented for supporting instructions of a JVM implementation; an SLSS domain operatively coupled to the processor and including one or more SLSS specific registers and one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor; and an IL domain operatively coupled to the processor and comprising one or more IL specific registers, wherein the functionality of the VMSS domain and the SLSS domain is provided to the processor in the IL domain by a system access of one or more of the registers. In one embodiment, the VMSS domain and the SLSS domain may operate in a first mode, and the IL domain may operate in a second mode, the second mode having access to the VMSS and SLSS specific registers. The first mode may comprise a C mode, and the second mode may comprise a Java mode. The one or more SLSS data structures may comprise a Memory Block data structure.

In one embodiment, a device may comprise: a VMSS means for implementing one or more VMSS data structures for supporting instructions of a JVM implementation; an SLSS means for implementing one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor; and an IL means for overlapping the functionality of the VMS means and the SLSS means and providing the functionality to the device. In one embodiment, the one or more SLSS data structures may comprise a Memory Block data structure.

In one embodiment, a method may comprise the steps of: implementing one or more VMSS data structures for supporting instructions of a JVM implementation; implementing one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of a processor; and making the functionality of the SLSS data structures available to each other through one or more VMSS and SLSS specific structures. In the method, the one or more SLSS data structures may comprise a Memory Block data structure. In the method, the one or more VMSS and SLSS specific structures comprise registers.

In one embodiment a system including a native instruction set may comprise: one or more circuit, the circuit including one or more mode specific registers a first domain operatively coupled to the circuit and including one or more of the modes specific registers for supporting instructions of a JVM implementation; a second domain operatively coupled to the circuit and including one or more mode specific registers for supporting structures compiled with an appropriate compiler to instructions belonging to a native instruction set of one of the system; and a third domain operatively coupled to the processor and comprising one or more mode specific registers, wherein the functionality of the first domain and the second domain is made available to the system in the third domain by an access of one or more of the mode specific registers. In one embodiment, the first domain and the second domain may operate in a first mode, and the third domain may operate in a second mode, the second mode having access to the mode specific registers of the first domain and the second domain. The first mode may comprise a C mode and the second mode may comprise a Java mode. Other aspects, embodiments, improvements, variations, and combinations will become apparent from the description provided herein and should be limited only by the claims that follow.

Description of Figures

In Figure 1, there is illustrated a representation of a VM, an operating system, and a hardware/processor layer, above which is an application layer; In Figure 2, there is illustrated functionality that may utilized in a system as provided by algorithms and/or data structures in VMSS, SLSS, and IL domains, respectively;

In Figure 3, there is illustrated the migration of one or more structures and the functionality they previously provided in one domain to an area that intersects with another domain; In Figure 4a, there is seen a diagram illustrating mode specific hardware registers;

Figures 4b and 4c illustrate embodiments in the context of the mode specific registers shown in Figure 4a;

In Figure 5, there is seen a representation of one embodiment of a Monitor Instance Definition and its relationship to a Class Object and a Class Object Instance Definition; In Figure 6, there is seen a representation of one embodiment of a relationship between an Object Instance and Monitor; and

In Figure 7, there is seen a representation of use of an offset with Heap Header during a process. Description Referring now to Figure 2 and other Figures as needed, there is illustrated functionality that may utilized in a system 100 as provided by algorithms and/or structures 101, 102, 103 in Virtual Machine Support Software (VMSS), System Loader and System Software (SLSS), and Interpretation Loop (IL) domains, respectively.

In one embodiment, the VMSS 101 (hereafter referred to as VMSS) may comprise one or more structures 104 as are known to those skilled in the software and operating system arts, for example, data structures for implementing virtual machine (VM) functionality such as stacks, object representations, class tables, methods structures and/or areas, thread representations, etc. The VMSS may also define functions or algorithms that operate on the structures. In one embodiment, the VMSS may exist in a domain supporting a Java Virtual Machine (JVM) implementation. In one embodiment, the VMSS may exist in a Java domain. In one embodiment, the Java domain may include use of Java and Java-like languages and structures, including as defined by Java 2 Standard Edition (J2SE), Java 2 Micro Edition (J2ME), and configurations such as Connected Limited Device Configuration (CLDC) available from Sun Microsystems, Inc., Palo Alto, California. Although the embodiments herein are described with reference to Java embodiments, it is understood that with appropriate modifications and alterations, the scope of the present invention encompasses embodiments that utilize other features and elements, including, but not limited to other Java and Java-like languages, structures, environments and software instructions similar in functionality to those disclosed herein to implement and use aspects of the present invention, for example, Common Language Interchange (CLI), Intermediate Language and Common Language Run-time (CLR) environments and C# programming language which are part of the .NET and .NET compact framework available from Microsoft Corporation Redmond, Washington; and/ or Binary Run-time Environment for Wireless (BREW) from Qualcomm Inc., San Diego, California. Thus, it is understood that the invention described herein should not be limited by the description contained herein, but only by the claims that follow.

After compilation, one or more applications 107 disposed in system 100 may utilize one or more of the VMSS structures 104, which may include, but are not limited to: Current Java Thread, Class Table, Monitors, Threads, Class Structure, Java Method Frame, Object Instance, Class Instance, Java Stack, and Java Registers structures (hereafter referred to by their proper name as such). Those skilled in the art will identify the Current Java Thread structure with a pointer used to represent the current Java execution context that can point to any virtual machine (VM) thread, and that may be used with Monitor structures; the Class Table structure with a structure used as an indexed list of all classes known by the executing VM; the Monitor structure with a structure used for thread synchronization and used to hold the context of ownership of an object; the Thread structure with a structure that represents an execution context of the underlying environment, with a thread either a native thread running under an operating system or a Java thread running on the VM; the Class Structure with a structure used as a union of all data elements that pertain to a given class used for instantiations, static field access, resolution, and method invocation; and the Java Method Frame structure with a structure used during the execution context of a method. In one embodiment, the SLSS 102 (hereafter referred to as SLSS) may comprise, but is not limited to, structures 105 that support management of resources such as memory, processor, and peripherals, bootstrap code, performance monitoring, and file and stream access, as well as input and output I/O operations. In one embodiment, the SLSS may exist in a C language domain. The invention described herein is, however, not limited to C, as other languages are also within its scope, for example, the SLSS functionality may be implemented to comprise other C-like language, C++, C#, SmallTalk, Ada, Java, assembly or Fortran, languages, which are all well known in the art. Although, in one embodiment, the SLSS comprises functionality normally provided by an operating system, the SLSS may differ from that of an operating system in that it does not require a safe environment where user programs may utilize system resources without fear of interfering with other user programs. Thus, simple kernels and application launchers can also be used as an SLSS and yet be within the scope of the invention described herein. In one embodiment, in an overlap between the VMSS and the SLSS domains described below, so-called Java data structures, while provided to support Java functionality, may in fact be coded in a C language.

In one embodiment, the SLSS may further comprise one or more other structures 105 as are well known to those skilled in the software, hardware, and operating system arts, including, but not limited to, Native Thread, Driver Structure, C Frame, Memory Block, Interrupt Flags, HW Peripheral, and Current C Thread structures (hereafter referred to by their proper names as such). In one embodiment, the SLSS may also define functions and algorithms that operate on the SLSS structures. As with the VMSS, the structures may be utilized by one or more applications 107.

In one embodiment, the Driver Structure may comprise a structure that may be used to represent a hardware peripheral logically; the Memory Block structure with units of memory used for dynamic memory allocation; the HW Peripheral structure with a structure used to communicate with physical or external resources; and the Current C Thread structure with a structure used to represent the current SLSS context for thread synchronization.

In one embodiment, a bootstrap Native Thread in the SLSS domain may be used to perform initializations of system 100 which includes invoking the VMSS. The VMSS may afterwards initialize its structures and start an Interpretation Loop (LL) and its structures. In one embodiment, the IL exists in a domain, which at a lowest level may comprise structures 106 that include a loop that performs instruction fetch, decode, and execute functionality that is well known to those skilled in the processor arts. In a software embodiment, this functionality may be enabled through a single inner function loop. In a hardware embodiment, the functionality may be characterized at a hardware level by implementing fetch, decode, and execute functionality with instruction fetch, decode, and execution unit blocks of a processor. In one embodiment, the functionality may be implemented as micro-coded instructions. In a hardware embodiment, hardware traps are part of the VMSS, and in a software embodiment, function calls outside of the inner function loop are part of the VMSS. This relationship defines the scope of the IL and VMSS domains and can be used to determine which function is associated with the IL and which one is not. The IL and VMSS domains may be thought of being complementary to each other, where the IL handles simpler, faster operations, and the VMSS handles exceptional or very complex cases. In one embodiment, wherein hardware implementing the IL does not provide microprogram branching functionality, the VMSS may handle operations that would require microprogram branching.

Referring now to Figure 3, and other Figures as needed, there is illustrated the migration of one or more structures and/or the functionality they previously provided in one domain to an area that intersects with another domain.

The arrows in Figure 3 are used to represent that in system 100, the VMSS, the SLSS, and the IL may be made aware of each others functionality by enabling the illustrated overlap of domains. For example, in one embodiment, the VMSS domain may be provided with visibility to the Memory Block and Interrupt Flags structures and what they consist of; and the SLSS domain may be provided with visibility to the Current Java Thread.

In one embodiment, certain ones of the structures previously provided in the VMSS domain are also provided or made accessible to or in the IL domain. The structures in the IL domain and the functionality they provide may be implemented as hardware, firmware, software, or combinations thereof. In one embodiment, one or more structures, for example, data structures, algorithms, an instruction set of a processor core, and/or registers in the IL domain, provide a means by which the VMSS, SLSS, and IL domains may overlap their functionality so as to be able to directly access each others functionality.

In one embodiment, by overlapping the functionality provided by the structures in the IL domain with certain functionality of the VMSS domain, the IL domain may be made aware of Monitors and Current Java Thread, which may enable thread synchronization to occur much faster. Also, with Class Table visible to the IL domain, faster class resolution may occur. By making Class Structure visible to the IL domain, faster method resolution may occur. Furthermore, by making Java Method Frame visible to the IL, faster invokes and returns may occur. In one embodiment, by overlapping the functionality provided by the structures in the

IL domain with certain functionality of the SLSS domain, such as by making Driver Structure visible to the VMSS domain, Java threads may be tied directly to interrupt events. Furthermore, by overlapping the IL domain with certain functionality of the VMSS and IL domains, the VMSS and IL domains may be made aware of C Frame such that faster native call execution may occur. Also, by making the VMSS domain aware of Memory Block, only one memory allocation space is needed, which provides benefits from statistical aggregation of the VMSS and the SLSS memory requirement, reducing block overhead and obviating the need for the partition of memory between the VMSS and the SLSS. In addition, by overlapping the domains, HW Peripherals may be made visible to both the VMSS and IL domains such that Java drivers may be efficiently implemented. Overlapping domains also allows the IL to execute instructions that require interactions with Monitor by telling the IL where a monitor is and how it is structured. Other overlaps and other benefits are also within the scope of the invention and will become evident from the description provided herein.

Referring to Figure 4a, and other Figures as needed, there is seen a diagram illustrating one or more mode specific hardware registers. One or more elements known to those skilled in the computer hardware, firmware, and software arts may be utilized to implement the embodiments described herein. For example, as illustrated in Figure 4a, a system 100 may include a memory 430, an Instruction Execution Unit (IEU) 443, a pre-fetch unit (PFU) 401, a microsequencer unit MSU 402, which are all elements that one skilled in the art would know how to implement to enable one or more of the embodiments described herein, and other than to the extent necessary, are not described any further herein. In one embodiment, system 100 may include a circuit or processor that implements one or more of the embodiments described herein. A processor implementing one or more of the embodiments herein may be provided with or in any number of other devices, including, but not limited to, mobile, fixed wireless, wired devices. In one embodiment, one or more of the embodiments described herein may be implemented in a wireless phone.

In one embodiment, the IL domain described above overlaps with Java Register structure functionality through the use of a set of mode specific data registers 470. In one embodiment, Java Register functionality interacts directly with the operation of the inner function loop operating in the IL domain. In one embodiment, system 100 includes two mode-specific control registers 470 that are provided for use in two operating modes. In the case of a system 100 having a Java mode used in the IL domain and a C mode used in the VMSS and JL domains, a set of Java mode control registers and a set of C mode control registers are provided. Overlapping functionality of the IL, VMSS, and SLSS domains may be provided by linking the structures to the mode specific registers using a class loader. In one embodiment the class loader supports data structures of a JVM implementation. In one embodiment, the registers may be implemented in hardware. In one embodiment, the registers may be implemented in software. In one embodiment, a mode-specific control register set 470 comprises a Java local variable (LP) pointer register 422, a Java stack pointer (SP) register 424, a Java program counter (PC) register 426, a C-local variable (LP) pointer register 472, a C-stack pointer (SP) register 474, a C-program counter (PC) register 476, a class table base 499 (CT) register, and a current class 498 (CC) register. C local variable (LP) pointer 472 points to the base of the active thread's C frame, while C stack pointer (SP) 474 points to the top of stack (TOS) of the active thread's C frame; similarly for the Java mode. Also, Java program counter (PC) 426 points to a memory location containing the next byte-code instruction to be executed in a method structure, C program counter (PC) 476 points to an instruction in a program in a C mode program space 435. C mode program space may comprise a plurality of opcodes 436 and operands 437, obtained by compiling C language program code using a C compiler specific to the instruction set of a processor core of a systemlOO.

In one embodiment, when system 100 is operating in C mode, a C stack 480 is employed - pushing and popping C frames as C functions are called and eventually return. Likewise, when system 100 is operating in Java mode, Java stack 440 is utilized, pushing and popping Java frames as Java methods are invoked and eventually return. In one embodiment, manipulation of C stack 480 is restricted to C mode instructions, however manipulation of Java stack 440 is permitted in both Java and C modes (i.e. both modes are "aware" of the Java stack, but only the C mode is aware of the C stack). Each pair of mode specific registers 470 may be accessed by the system 100. In one embodiment each mode specific register 470 may be individually addressable. In one embodiment, instructions of the processor's instruction set may be implemented to force a test on a mode bit or bits to determine which of the mode specific registers 470 to use. In one embodiment, two or more versions of a given instruction may be provided, one version per mode, wherein each version is implemented to operate in a specific way on memory. For instance, a push instruction may be provided for both a Java mode and a C mode, wherein the Java push instruction accesses the stack pointer value stored specifically in the Java stack pointer register 424, and the C push instruction accesses the stack pointer value stored in a C stack pointer register 474. In one embodiment, the mode specific registers 470 may be addressable as "alt-reg"

420, and as "current-reg" 430, representing alternate and current mode registers, respectively, the contents of which may be defined by the value of the mode bit or bits at a given moment of execution.

Figures 4b and 4c illustrate an embodiment in the context of the mode specific registers shown in Figure 4a. In one embodiment, where certain instructions are common to both a Java and a C mode, and where those instructions require use of one of the mode specific registers of the current mode being executed, microprograms associated with the instructions may be used as "templates", similar to the concept found in C++ programming. In this manner, shared microprograms need not account for mode in deciding which of the sets of mode specific registers 470 to use. Swap logic such as that depicted in Figures 4b and 4c may provide implicit addressing of a current register (current-reg) 440 and an alternate register (alt-reg) 450. As such, a microprogram may be mode-agnostic and only need to address the current register and alternate register as needed with the correct value provided from the Java 400 or C 410 registers by swap logic. Those skilled in the art will understand that while certain aspects of the present invention are discussed in terms of "microprograms" or "microinstructions", many aspects could equally apply to hardwired embodiments.

By providing alt-registers and current-registers, fast mode switching between a first mode and a second mode may be provided and operations in one mode that need to manipulate a context of another mode are facilitated. For example, in a Java native processor that implements instructions of the JVM instruction set and a set of extended instructions, the first mode may comprise the Java mode, and the second mode may comprise the C mode. Advantageously, the Java native processor may implement certain opcodes of the JVM instructions set in the IL domain as microcode in hardware in a Java mode, while a second set of opcodes of the JVM instruction set may be trapped, or trappable, and may handled by a trap-handler. Other processor architectures besides microcoded machines are also within the scope of the description provided herein, for example, hardware JITs, VLIW, RISC, etc. The trap-handler, which may require functionality beyond what is provided by the instruction available in the JVM instruction set, may comprise a sequence of one or more extended instructions (with respect to the JVM instruction set) and the aforementioned hardware implemented JVM instructions. To this end, trap handlers may either be developed in native assembler or in any suitable programming language for which a compiler is provided to compile the language to the native instruction set of the target system. In one embodiment, trap handlers may be developed for use in the SLSS domain using the C programming language, thus extended mode operations may be referred to as C mode operations. Thus, embodiments of the invention provide efficient execution of program code comprising more than one instruction set, for example, as may be provided by the VMSS and SLSS domains described herein. Current Java Thread

Referring to Figure 5 and other Figures as needed, there is seen a representation of an implementation of an embodiment of a Class Table and a Class Object Definition. In one embodiment, the IL domain overlaps with Current Java Thread and Class Table functionality through the mode specific Class Table Base (CT) register 499, which contains the absolute address of the Class Table in RAM. The address is a pointer to the class table, which itself contains pointers to data structures for loaded classes and their static instances and the first element of which is the current thread ID.

The Class Table is allocated at initialization and typically does not grow beyond the starting size. Growing the table would require allocating a new larger memory block and copying the contents over to the new block before updating the CT register 499. The Class Table Base value is a root for garbage collection purposes. In one embodiment, the Current Thread ID is the ID of the currently executing thread and the pointer to the thread record, and is set upon performing a thread swap. It is also used by monitorenter, monitorexit, and synchronized invokes to set the Owner field of a Monitor. Class Count is the count of classes loaded in the system and Class Count Maximum is the maximum count of classes loadable in the system. Class Pointer points to the absolute address of the class data, and Class Object Instance points to the absolute address of the static Class Object Instance.

The Class Pointer from the Class Table is used to locate Class Objects. Class Objects occur once per class. The table and other portions are logically grouped with the class, but are not physically grouped. The intention is that all the parts of the Class Object are grouped in a single memory allocation object for compactness. In one embodiment, the collection order is that that the Class part appear first and be immediately followed by a Method Entries Pointer Table. The Class Pointers from the Class Table are used to locate Class Objects.

Monitor

Referring further to Figure 5 and other Figures as needed, there is seen a representation of one embodiment of a Monitor Instance Definition and its relationship to a Class Object and a Class Object Instance Definition. Class Object Instances contain the Class static data. In one embodiment, the IL domain overlaps with Monitor functionality. The IL may contain a hardware microprogram instructing the IL on how to execute instructions, which involve Monitors, such as synchronized methods. The microcode may be executed upon the decoding of a monitorenter or monitorexit instruction. The VMSS also may operate on the same Monitors by having an internal description of the data structure as well as program sequences instructing the VMSS on how to execute instructions or system functions that involve Monitors, such as a synchronized methods of a complexity such that it is not practical for the IL to execute, or the killing of a thread, which requires the inspection of all monitors in a system, as is common in the arts of operating system design.

Threads

In one embodiment, the IL domain overlaps with Threads functionality through a register which holds a pointer, the pointer pointing to a data structure containing Current Thread, hi one embodiment, the overlap may be provided through a CT register 499 pointer, which points directly to a data structures for loaded classes and their static instances, and whose first element is the Current Thread. A class loader may maintain the Class Table. In one embodiment, the first element may comprise an I.D.#, index, pointer, etc... . Upon the execution of a Java instruction which requires the IL to know the Java thread context, the IL can retrieve that information from the Current Thread. For instance, the execution of synchronized invokes require the IL to be aware of its Java thread context to decide whether it can proceed or must stop because it has to operate on a locked object.

Class Structure

In one embodiment, the IL domain overlaps with Class Structure functionality through the use of an address calculation unit (ACU). The ACU may implement, in hardware, offsets to frequently used data structures, for example, to Class Table, Monitors, and others, including those described herein to exist in the VMSS and EL domains.

Java Frame Method

In one embodiment, the IL domain overlaps with Java Method Frame through the functionality provided by the mode specific Frame Pointer (FP) 423, Stack Pointer (SP) and Local Variable (LP) registers referenced previously. In one embodiment, Java Method Frame may also be accessed though the alt-reg registers 420, 430, 440, 450 described above when software traps occur.

Object Instance and Class Instance

Referring to Figure 6 and other Figures as needed, there is seen a representation of one embodiment of a relationship between an Object Instance and Monitor. Object Instances occur many time per Class. In one embodiment, Class Pointer points to the absolute address of the Class data and Monitor Pointer points to the Monitor Instance for the Class Object Instance. A Monitor Instance is allocated on demand.

In one embodiment, the IL domain overlaps with Object Instance and Class Instance functionality through the CT register 499 and CC register 498, elements of which may be addressed using specific offsets in microcode and the above referenced ACU. The CC register may be split into two halves, the upper half containing the index into the system Class Table of the Class Entry for the Class of the currently executing method, and the lower half containing the index into a Method Table of the current class for this method. In one embodiment, this register may be maintained by microcode during invocations and returns. Trap handlers may access or modify this value.

Java Stack

In one embodiment, the IL domain overlaps with Java Stack functionality through the above referenced FP, SP, LP registers, as well as the mode specific Stack Limit (SL) register 424 that contains the last available entry (lowest address) of the current Java stack chunk. The SL register 424 may be used in method invocations to determine if sufficient room remains in the current stack chunk for the segments of a method frame. In one embodiment, the method frame segments may comprise Local Variable, Frame, and Local Stack segments. The method frame segments may be split across the end of an old chunk and the beginning of a new chunk. Driver Structure/HW Peripherals

In one embodiment, the IL domain overlaps with the Driver Structure and Hardware Peripherals functionality through "method filter" functionality added to the VMSS. In one embodiment, a standard class loaders is used by the NMSS to load class file data into runtime JNM data structures, which may include the collection of stacks, the heap, class table, object instances, etc. In one embodiment, the SLSS domain may also include a class loader. The method filters also do some amount of verification. The method filter functionality may be added to a class loader provided in the VMSS. The bytecodes used to replace these are non-JVM extended opcodes specified to provide direct memory access (iregload and iregstore). The iregload and iregstore instructions may be provided with the address of a register as an operand (as in opcode +operand(s)), the iregload pushing the contents of that register onto the stack through the SP, the iregstore popping the top of stack through the SP and storing the data in the register. In this manner, the IL may be enabled to support device driver code to operate directly on hardware through instructions which were generated by the method filter. In one embodiment the method filter replaces static method calls from a Memory class with an appropriate register instruction, for example, a int Memory.read(address) becomes "push address; and an iregload;" void Memory .write(address, data) becomes "push data; push address; iregstore. . The "method filter" functionality may be added to a class loader provided in the

VMSS of system 100. The bytecodes used to replace these are non-JVM extended opcodes specified to provide direct memory access (iregload and iregstore). In this manner, the IL may be enabled to support device driver code to operate directly on HW peripherals through instructions which were generated by the method filter.

Memory Block

In one embodiment, the IL domain overlaps with Memory Block functionality through implementation of microcode at the hardware level and through the use of heap headers. In one embodiment, all allocated memory is linked in a "heap" data structure, all the way back to a root. Each piece of contiguous allocated memory has a "heap header" that includes, among other things, pointers to the next and previous pieces of allocated memory in the heap, h one embodiment, the VMSS uses garbage collection (GC) to traverse all allocated memory. In one embodiment, the heap header contains GC bits to indicate the status (white, gray, black) of that piece of memory. The microcode can access these bits to indicate that a piece of memory has been referenced for example, to indicate to the GC not to deallocate. The header may be accessed by applying a pre-determined offset using the ACU (defined by the known structure of the heap header & the data structure to which it is attached).

Referring now to Figure 7, and other figures as needed, there is seen a representation of use of an offset with Heap Header during a process where if the stack pointer SP[0] is null then a "trap" is invoked and RAM is read at the address SP[0]-4 to temp, temp is OR'ed with 1, and temp is written to RAM at address SP[0]-4. In one embodiment, the process represented by the Figure 10 may comprise part of a byte code for returning across stack chuck boundaries if they are set properly in a trapped by Stack Limit invoke. The code performs a write block, "graying" Object header garbage collection bits. The sequence drops out a null pointer to avoid an illegal read and write to oxffff fffc so the trap handler consists of only a "cret" byte code, with which the following sequence of events occurs to return to a C mode: clear the Stack to 0, Pop the LP, Pop the PC.

Current C Thread In one embodiment, because multiple C (aka native) threads are not needed, because only a single native thread at start-up that initializes everything and starts a first Java thread is needed, Current C Thread is not needed. The first (or base) Java thread may handle creating new threads using standard Java methods and classes - e.g. runnable interface and thread class.

Numerous modifications and variations of the present invention are possible in light of the above embodiments described herein, for example, using various technologies known to those skilled in the art, for example, using hardware and software technologies, including, but not limited by, computer readable medium to implement one or more elements of the embodiments discussed herein. A computer readable medium is any medium known in the art capable of storing information. Computer readable media include Read Only Memory (ROM), Random Access Memory (RAM), flash memory, Erasable-Programmable Read Only Memory (EPROM), non-volatile random access memory, memory-stick, magnetic disk drive, floppy disk drive, compact-disk read-only-memory (CD-ROM) drive, transistor-based memory, or other computer-readable memory devices as is known in the art for storing and retrieving data, for example, SRAM, latches, flip-flops, registers, and the like. Also, as described herein the structures provided by a VMSS more generally may provide support for Java functionality and are not necessarily limited by Java code. For example, the structures described herein could be coded in Java would be in a full software embodiment (i.e. a simulator) or in a hardware embodiment if the Java code was compiled using an unconventional compiler that compiles the Java language to a specific processor instruction set and not to the JVM. Furthermore, other languages are within the scope of those described herein, including Java 2 Standard Edition (J2SE), Java 2 Micro Edition (J2ME), and configurations such as Connected Limited Device Configuration (CLDC) available from Sun Microsystems, Inc., Palo Alto, California; and other Java or Java-like languages, for example, Common Language Interchange (CLI), Intermediate Language (IL) and Common Language Run-time (CLR) environments, and C# programming language which are part of the .NET and .NET compact framework available from Microsoft Corporation Redmond, Washington; and Binary Run-time Environment for Wireless (BREW) from Qualcomm Inc., San Diego, California. Furthermore, C, C++ data structures, etc. described herein may be more generally defined as code of a chosen language, compiled with an appropriate compiler to instructions belonging to a native instruction set of a processor, for example, that includes the functionality provided by the IL describe herein. Where the processor comprises a Java technology-based native processor, the native instruction set may include the JVM instruction set, augmented with one or more instructions permitting, among other things, direct memory and register access. It is therefore understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Claims

What is Claimed is:

1. A system, comprising: a VMSS domain, the VMSS domain including one or more VMSS data structures; an SLSS domain, the SLSS domain including one or more

SLSS data structures; and an IL domain, wherein the SLSS data structures and the

VMSS data structures comprise functionality that overlaps in the IL domain; and one or more computer readable medium, wherein the VMSS and

SLSS data structures are implemented by the computer readable medium and wherein the system interacts with the data structures via the computer readable medium.

2. The system of Claim 1, the VMSS domain comprising one or more VMSS specific registers; the SLSS domain further comprising one or more SLSS specific registers; and the IL domain further comprising one or more IL specific registers, wherein the overlap of the functionality in the IL domain is provided by a system access of one or more of the registers.

3. The system of claim 1, wherein the VMSS data structures comprise data structures for supporting a JVM implementation.

4. The system of claim 3, wherein the VMSS data structures comprise data structures selected from a group consisting of Current Java Thread, Monitors, and Threads data structures.

5. The system of claim 4, wherein the SLSS data structures comprise a Memory Block data structure.

6. The system of claim 4, wherein the SLSS data structures comprise a Hardware peripherals data structure.

7. The system of claim 4 wherein the SLSS data structures are compiled with an appropriate compiler to instructions belonging to a native instruction set of the system.

8. The system of claim 1 , wherein the IL domain includes one or more pointer, including one or more VMSS mode specific pointer and one or more SLSS mode specific pointer.

9. The system of claim 1, wherein the IL domain includes instruction fetch, decode, and execute functionality; and wherein the IL domain includes one or more domain specific pointer.

10. The system of claim 9, wherein the one or more domain specific pointer is embodied by the computer readable medium as software.

11. The system of claim 9, wherein the one or more domain specific pointer is embodied by the computer readable medium as hardware.

12. The system of claim 11, further comprising a processor, wherein the VMSS data structures comprise data structures provided to support Java functionality, wherein the SLSS data structures comprise data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the system, and wherein the processor is operatively coupled with the computer readable medium so as to provide the functionality that overlaps in the IL domain to the system.

13. The system of claim 12 wherein the IL domain is provided as a hardware implementation selected from the group consisting of microcode, hardwired logic, and a combination of microcode and hardwired logic.

14. A device, comprising: a VMSS domain, the VMSS domain including functionality provided by one or more VMSS data structures, the one or more VMSS data structures including a Current Thread, a Class Table, and a Monitors data structure; an SLSS domain, the SLSS domain including functionality provided by a Memory Block data structure; an IL domain, the IL domain including functionality, wherein the functionality provided by the SLSS and VMSS data structures is compiled to the IL functionality.

15. The device of claim 14, wherein the VMSS data structures comprise Java data structures.

16. The device of claim 15, the device comprising a processor, wherein the SLSS data structures comprise data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor.

17. The device of claim 16, wherein the IL functionality comprises one or more pointers.

18. The device of claim 16, wherein the IL functionality is embodied as one or more registers.

19. The device of claim 18, wherein the IL functionality is embodied as a Java Register data structure.

20. The device of claim 18, wherein the one or more registers comprise one or more mode specific registers.

21. The device of Claim 14 wherein the IL functionality comprises a processor having an instruction set, the instruction set including a first instruction group of JVM instructions and a second instruction group comprising platform dependant instructions, the instruction set supporting the execution of a first set of JVM instructions in hardware, the processor trapping to VMSS functionality to support the execution of a second set of JVM instructions with a sequence of one or more platform dependant instructions.

22. A method of overlapping functionality, comprising the steps of: providing a set of mode specific registers; providing one or more data structures; and linking the data structures to the mode specific registers using a class loader.

23. The method of claim 22, wherein the class loader supports data structures of a JVM implementation.

24. The method of claim 22, wherein one or of the mode specific registers comprise Java registers and wherein one or more of the mode specific registers comprise C registers.

25. The method of claim 24, wherein the one or more data structures include Current Java Thread, Class Table, Monitors, Threads, Class Structure, C Frame, Memory Block, and HW Peripherals data structures.

26. A processor based system, comprising: a VMSS domain operatively coupled to the processor and including one or more

VMSS specific registers and one or more VMSS data structures implemented for supporting instructions of a JVM implementation; an SLSS domain operatively coupled to the processor and including one or more SLSS specific registers and one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor; and an IL domain operatively coupled to the processor and comprising one or more IL specific registers, wherein the functionality of the VMSS domain and the SLSS domain is provided to the processor in the IL domain by a system access of one or more of the registers.

27. The system of claim 26, wherein the VMSS domain and the SLSS domain operate in a first mode, and the IL domain operates in a second mode, the second mode having access to the VMSS and SLSS specific registers.

28. The system of claim 27, wherein the first mode comprises a C mode, and the second mode comprises a Java mode.

29. The processor of claim 28, wherein the one or more SLSS data structures comprise a Memory Block data structure.

30. A device, comprising: a VMSS means for implementing one or more VMSS data structures for supporting instructions of a JVM implementation; an SLSS means for implementing one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of the processor; and an IL means for overlapping the functionality of the VMS means and the SLSS means and providing the functionality to the device.

31. The device of claim 30, wherein the one or more SLSS data structures comprise a Memory Block data structure.

32. A method comprising the steps of: implementing one or more VMSS data structures for supporting instructions of a JVM implementation; implementing one or more SLSS data structures compiled with an appropriate compiler to instructions belonging to a native instruction set of a processor; and making the functionality of the SLSS data structures available to each other through one or more VMSS and SLSS specific structures.

33. The method of claim 32, wherein the one or more SLSS data structures comprise a Memory Block data structure.

34. The method of claim 32, wherein the one or more VMSS and SLSS specific structures comprise registers.

35. A system including a native instruction set, comprising: one or more circuit, the circuit including one or more mode specific registers a first domain operatively coupled to the circuit and including one or more of the modes specific registers for supporting instructions of a JVM implementation; a second domain operatively coupled to the circuit and including one or more mode specific registers for supporting structures compiled with an appropriate compiler to instructions belonging to a native instruction set of one of the system; and a third domain operatively coupled to the processor and comprising one or more mode specific registers, wherein the functionality of the first domain and the second domain is made available to the system in the third domain by an access of one or more of the mode specific registers.

36. The system of claim 35, wherein the first domain and the second domain operate in a first mode, and the third domain operates in a second mode, the second mode having access to the mode specific registers of the first domain and the second domain.

37. The system of claim 36, wherein the first mode comprises a C mode and the second mode comprises a Java mode.