CN1596398A - Software support for virtual machine interpreter (VMI) acceleration hardware - Google Patents

Abstract

A system and method for processing virtual machine instructions which supports the software trap methodology. An application programming interface (API) prescribes additional functionality for software traps that remove the processing of recursive virtual machine instructions from virtual machine hardware and instead process recursive virtual machine instructions using software. The additional functionality includes the configuration of a context for processing recursive virtual machine instructions, which enables the virtual machine instructions to access CPU registers to retrieve and modify the values of variables as required, the release of the configured context when processing of recursive virtual machine instructions is completed, and the return of control to a virtual machine for processing non-recursive virtual machine instructions.

Description

Software support for virtual machine interpreter (VMI) accelerated hardware

field of invention

The present invention relates generally to computer programming languages, and more specifically to the translation and execution of virtual machine languages.

Background of the invention

Computer programming languages are used to create applications consisting of human-readable source code representing instructions for computer execution. However, before a computer can follow these instructions, the source code must be translated into computer readable binary machine code.

Programming languages such as C, C++ or COBOL typically use a compiler to generate assembly language from source code, which is then translated into machine language which is converted into machine code. Thus, the final translation of the source code occurs before runtime. Different computers require different machine languages, so a program written in, for example, C++ will only run on the specific hardware platform for which the program was written.

Interpreted programming languages are designed to create application programs with source code that will run on multiple hardware platforms. Java ^(TM) is an interpreted programming language that achieves platform independence by generating source code that is converted before runtime into an intermediate language known as "bytecode" or "virtual machine language". At runtime, the bytecode is translated into platform-appropriate machine code by interpreter software, as disclosed in US Patent No. 4,443,865. To interpret each bytecode, the interpreter software performs a "fetch, decode, dispatch" (FDD) series of operations. For each bytecode instruction, the interpreter software includes a corresponding executive program represented by a native central processing unit (CPU) instruction. The interpreter software causes the CPU to fetch or read a virtual machine instruction from memory, decode the CPU address of the executive program for this bytecode instruction, and transfer control of the CPU to that executive program to schedule. This interpretation process can be time consuming.

Adding a preprocessor (Virtual Machine Interpreter (VMI)) between the memory and the CPU improves the processing of virtual machine instructions, as disclosed in PCT Patent Application No. WO9918484. In fact, a virtual machine is not a physical structure, but a self-contained operating environment that interprets bytecodes for the hardware platform by selecting the corresponding native machine language instructions stored in the VM or in the CPU. The native instructions are then provided to the CPU of the hardware platform, and these instructions are continuously executed in the CPU of the hardware platform. A typical virtual machine requires 20-60 cycles of processing time per bytecode (depending on the quality and complexity of the bytecode) to execute the FDD sequence of operations.

Further reductions in processing time can be achieved by implementing hardware accelerators, as disclosed in PCT Patent Applications Nos. WO9918484 and WO9918486. First, the VMI reads (fetches) a bytecode from memory. The VMI then looks at various attributes of the fetched bytecode (decoding). One of the attributes accessed by the VMI indicates whether the bytecode is simple or complex, which determines whether the VMI can translate the bytecode in hardware. The VMI translates simple Java ^TM bytecode into specialized and optimized sequences of native CPU instructions, which are then fetched and executed by the CPU. While the CPU is executing an instruction, the VMI fetches the next bytecode and translates it into a CPU instruction. VMI is able to process simple bytecodes in 1-4 cycles. If its properties indicate that the bytecode is complex, the VMI generates a generic sequence of native CPU instructions, implementing a "software trap" that directs the complex bytecode to software for translation and execution. Once a complex bytecode is encountered, the VMI issues machine code instructions to the CPU, thereby executing the corresponding native function, ie, executing a machine code subroutine residing in the CPU. In response, the CPU interrupts execution of native instructions generated by the VMI as a result of previous bytecode translations, and executes native functions called by the complex bytecode. The VMI waits to detect a new fetch operation from its output buffer, and then resumes translation of the bytecode sequence. Although VMI accesses existing native functions instead of translating complex bytecode instruction-by-instruction, it reduces the operational time impact of FDD to almost 0 cycles because, VMI processing of each software trap (5-20 cycle) is concurrent with the CPU execution of another bytecode.

While interpreting a bytecode sequence, the virtual machine may encounter a "recursive" complex bytecode. Difficulty arises when executing recursive bytecodes (RBCs), because each RBC calls a native function that ultimately results in a method call (i.e., restarts for another sequence of Java bytecodes). VMI). Therefore, in order to decode bytecode from another sequence, native functions called by RBC must access variable values stored in CPU registers. Native functions usually (but not always) include a standard instruction set, hereinafter referred to as "preamble" and "postamble". The standard preamble is designed to save the contents of some or all of the CPU registers before executing the subroutine. Some of what is saved concerns variable values that may need to be modified during execution of the native function (such as the stack pointer and return address for restarting the virtual machine). However, it is generally not possible to access these variables within native functions specified by RBC, because RBC method calls are defined in the source code of the programming language, not in the machine code that is required to access CPU registers. Furthermore, because RBC method calls cannot access CPU registers, standard subroutine postambles cannot write variable values that have been modified by RBC method calls back into CPU registers. In other words, because RBC subroutines cannot access variables stored in CPU registers either due to lack of environment settings (no preamble or postamble), or due to incompatible environment settings associated with native function calls, it is possible Subroutines called from recursive bytecode cannot be executed correctly. This difficulty can be solved by implementing hand-coded software that generates assembly language to write or modify variable values for RBC subroutines, however this approach requires a complex development effort.

There is a need for a system that interprets a programming language that accurately and efficiently executes instructions specified by recursive bytecode while being easier to implement.

Summary of the invention

The present invention satisfies the needs described above by specifying a dedicated function that provides a preamble and a postamble to a native function called by recursive bytecode and executes the native function. The preamble and postamble replace or modify any standard preamble and postamble associated with the native function and enable the native function to access and modify the contents of the necessary CPU registers. In another embodiment, specific functions can be fetched from processor memory, or generated for bytecodes of any complexity. By doing so, the present invention maintains accuracy and speed while simplifying the implementation of a software trap or "VMI accelerated hardware" approach.

More specifically, the present invention provides VMI support in the form of an application programming interface (API). When the VMI encounters recursive bytecode while interpreting and executing bytecode sequences, the VMI support software of the present invention uses an additional preamble and an additional postamble to convert the highest layer called by the recursive bytecode Subroutines are encapsulated. When the subroutine is called, the additional preamble of the present invention processes the variable values contained in the CPU registers, causing the CPU to write these values into variables accessible inside the called subroutine. In this way, the called subroutine can modify the variable value. The additional postamble of the present invention is executed after the standard subroutine postamble, causing the CPU to fetch the value of the modified variable and write the value into a CPU register. Thus, the modified variables will be available when the CPU resumes execution of the native instructions resulting from the subsequent translation of the bytecode.

Briefly, the present invention includes a method and system for processing virtual machine instructions, which in an exemplary embodiment of the present invention are generated by the Java programming language. At the programming level, Java source code is compiled into an intermediate language called bytecode. The bytecode includes virtual machine instructions that can be interpreted by the virtual machine for execution by the processor. According to an exemplary embodiment of the present invention, a virtual machine (VMI in this exemplary embodiment) is initialized at runtime. A table is compiled that includes the entry addresses of all software traps that remove the processing of some complex bytecode from the VM hardware and use software to process the complex bytecode instead. Parameters are initialized that classify the bytecodes according to the appropriate processing method for each bytecode's characteristics. For example, bytecode can be classified as simple, complex, or recursive (RBC). A recursive bytecode is a virtual machine instruction in the first sequence of bytecodes that invokes one or more bytecodes in the second sequence of bytecodes that execute and then returns to the first sequence of bytecodes subroutine. Examples of recursive Java bytecodes are INVOKESTATIC and NEW. Those software traps configured to handle RBCs are equipped with appropriate preambles and postambles.

The VMI proceeds to translate each of a series of bytecodes into one or more native machine instructions. When an RBC is encountered, the VMI suspends the translation of the bytecode sequence and handles the RBC through the appropriate software trap. In general, software traps retrieve native functions corresponding to the RBC's virtual machine instructions. The Application Programming Interface (API) of the present invention specifies appropriate subroutines that execute the preamble, call the native function corresponding to the RBC, and execute the postamble. The preamble is executed prior to execution of native functions called by the RBC. The postamble is executed after execution of the native function called by the RBC and after any RETURN (return) statements in the RBC native function. If the subroutine called by the RBC contains a standard preamble and/or a standard postamble, the preamble of the present invention is replaced and usually executed before executing the standard preamble, and the present invention The postamble is replaced and is usually executed after the standard postamble is executed. In addition, the preamble and postamble of the present invention can physically modify or rewrite one or more instructions included in the standard preamble or the standard postamble, respectively. According to an aspect of the exemplary embodiments of the present invention, the preamble writes a value to a variable accessible by a subroutine called by the RBC. The postamble of the present invention writes the variable value modified by the called subroutine back to the CPU register containing the variable. Then, the subroutine specified by the API starts to resume the translation in the VMI of the bytecode sequence, which will continue until another RBC is encountered or the translation process is terminated. Also, subroutines specified by the API may execute preambles and postambles as needed to enable native operation to access the VMI environment, for example, executing the first preamble before native processing begins , the first postamble before the above method is processed, another preamble after the above method is executed, and the final postamble after the processing of the local machine is completed.

Resume VMI translations using code such as the C RETURN statement. However, in an exemplary embodiment of the invention, the C RETURN statement issued by the RBC is added by the recovery subroutine for releasing the CPU region configured to handle the RBC's environment, and VMI execution is returned into the bytecode sequence A position of , for example, returns to the position immediately following the most recently translated RBC.

Another aspect of the invention is a system for executing virtual machine instructions from an interpreted language such as Java ^(TM) . The system includes a processor (CPU) and preprocessor (VMI), an instruction memory, a translator (JVM), and an application programming interface (API). The processor includes and is configured to execute hardware-specific instructions, hereinafter referred to as native instructions. The preprocessor is a virtual machine, such as a VMI, configured to fetch bytecodes from an instruction memory and translate the bytecodes into native CPU instructions. For certain types of bytecodes, the API is configured to write values from CPU registers to variables accessible to the native CPU instruction represented by said bytecode and to The native CPU instruction represented by the code modifies the value of the variable. In an exemplary embodiment of the present invention, the API specifies a subroutine that implements a preamble prior to execution of a subroutine called by the bytecode and implements a postamble after that execution. The preamble writes a value from a CPU register to a variable accessible by the called subroutine. After executing the instructions represented by this bytecode, the API modifies the variable values accordingly by executing postamble subroutines.

Although a software trap method can be implemented in conjunction with the API of the present invention to handle various types of bytecodes, this exemplary embodiment of the present invention is intended to handle recursive bytecodes.

The present invention can be implemented in a system that executes Java ^(TM) bytecode using a virtual machine, such as the JVM manufactured by Sun Microsystems. However, the present invention can also be implemented using other Java ^™ virtual machines such as the Microsoft virtual machine, and is also applicable to systems executing other interpreted languages such as Visual Basic, dBASE, BASIC and MSIL (Microsoft Intermediate Language).

Additional objects, advantages and novel features of the invention will be set forth in part in the ensuing description and in part will be apparent to those skilled in the art from a study of the following, or may be learned by practice of the invention.

Brief description of the drawings

Figure 1 is a block diagram illustrating the functional elements of an exemplary embodiment in the context of the present invention.

Figure 2 shows an exemplary bytecode processing sequence.

Fig. 3 is a flowchart of a method according to an exemplary embodiment of the present invention.

Figure 4 is a timeline illustrating the relative timing of operations involved in an exemplary embodiment of the present invention.

DESCRIPTION OF THE BEST EMBODIMENTS

Referring now in detail to an exemplary embodiment of the present invention, which is illustrated in the drawings, wherein like reference numerals designate like parts, FIG. 1 is a block diagram of an exemplary embodiment in the context of the present invention. The basic components of this environment are hardware platform 100 , which includes processor 110 , preprocessor 120 and instruction memory 150 , which are all connected by system bus 160 . The preprocessor 120 includes at least one table 130 and a translator 140 . Hardware platform 100 typically includes a central processing unit (CPU), basic peripherals, and an operating system (OS). The processor 110 in the present invention is a CPU such as a MIPS, ARM, Intel ^™ x86, PowerPC ^™ or SPARC type microprocessor, and contains and is configured to execute hardware-specific instructions, hereinafter referred to as native instructions. In an exemplary embodiment of the invention, the translator 140 is a Java ^™ Virtual Machine (JVM), such as KVM manufactured by Sun Microsystems. Preprocessor 120 in this exemplary embodiment is preferably a virtual machine interpreter (VMI) disclosed in WO9918486 and is configured to fetch bytecode from instruction memory and translate the bytecode into native CPU instruction. The VMI 120 is a peripheral device on the bus 160 that can act as a memory-mapped peripheral device, wherein a predetermined range of CPU addresses is assigned to the VMI 120 . VMI 120 manages individual virtual machine instruction pointers for indicating current (or next) virtual machine instructions in instruction memory 150 . The instruction memory 150 contains virtual machine instructions, for example Java ^™ bytecode 170 .

The VMI 120 accelerates the interpretation of Java bytecode 170 by translating most of the bytecode 170 into an optimal sequence of native CPU instructions. However, VMI 120 implements a software solution for handling complex bytecode 170 by executing software traps. In general, the present invention relates to systems and methods for extending the execution capabilities of software traps that target a specific type of complex bytecode, known as recursive bytecode (RBC) 230 . Fig. 2 shows the important feature of RBC 230, that is: the processing to the RBC 230 in the first series 210 of bytecode 170 will cause the processing of bytecode 170 in the second series 220 of bytecode 170 and then return to processing bytecode 170 in series 210 . Thus, executing RBC 230 produces bytecode subroutines called "methods". Note that if series 210 is equal to series 220, then series 210 constitutes a "recursive method", which term is not equivalent to "recursive bytecode". The present invention can support generic operations for handling software traps of the RBC 230 by defining an API that includes a general structural specification of software traps.

According to the present invention and with reference to FIG. 3, the VMI 120 is initialized at runtime, a process that includes setting the translation control registers of the VMI 120. A table 130 is compiled which includes entry addresses for all software traps. Parameters are initialized that allow the VMI to process each bytecode according to the properties of the bytecode. When the bytecode is complex, the VMI handles the bytecode through appropriate software traps. According to the present invention, those software traps configured to handle the RBC 230 involve appropriate preambles and postambles, as part of the generic sequence of native instructions that together form the software traps. can be generated by VMI 120, but in the exemplary embodiment they are stored in, instantiated in, and executed from processor memory. Additionally, the preamble and postamble can be stored in a table 130 within the VMI. Thus, in an API implementation, each RBC software trap entry point is programmed to point to a native subroutine ("PPA subroutine") once the system is initialized. The PPA subroutine includes an execution preamble and postamble, and has been instantiated to contain a jump to a native function (or native functions) called by the RBC.

As one example of the operation of the present invention, VMI 120 proceeds to translate each of series 210 of bytecode 170 into one or more native instructions. Referring to FIG. 2, bytecodes B0 through B2 are non-recursive, so VMI 120 simply fetches B0 through B2 from instruction memory 150, selects the native instruction or instructions defined for each bytecode 170, and provides these instructions to the processor 110 for execution. Bn is the RBC 230 whose execution may cause the execution of one or more bytecodes from the second sequence 220 (here Bo to Bs). Note: In Java, method calls always enter the sequence at the first bytecode, however other languages may not allow entry at other locations along an instruction sequence for no technical reason. After executing the bytecode in the second sequence 220 , Bs is a RETURN bytecode that causes bytecode execution to continue somewhere in the first sequence 210 . As indicated by Bs which is not the last bytecode of sequence 220, a Java method can have several exit points (RETURN bytecode). After Bs, execution typically continues at Bn ₊₁ in the first sequence 210, but this does not have to be the case.

As shown at block 310 in FIG. 3 , the VMI 120 increments the virtual machine counter by one before proceeding to block 320 to fetch each bytecode 170. In block 330, VMI 120 responds to Bytecode 170 is decoded. If there is a current hardware translation for the bytecode 170, the method proceeds to block 370 and processes the simple bytecode accordingly. A bytecode 170 is complex if there is no hardware translation for the bytecode 170 . In block 340, the bytecode 170 is checked against parameters in the VMI table 140 that may identify the appropriate generic sequence of native instructions for the complex bytecode. The VMI 120 suspends the translation of the sequence 210 of bytecode 170 and processes the complex bytecode according to this generic sequence that constitutes the appropriate software trap, whose address is located in table 140. Software traps typically handle complex bytecodes by retrieving the native function corresponding to the bytecode 170 and dispatching the native function to the CPU 110, rather than by interpreting the subroutines represented by the bytecode 170 instruction by instruction. The application programming interface (API) of the present invention is a technical specification that specifies the functions required to extend the software trap method when implementing RBC processing, and specifies how to access the functions. If, as assumed in block 380, bytecode 170 is not recursive, then in accordance with the appropriate software trap identified in block 340, perform native operations in block 384 until control is returned as in block 368 to VMI. If, as assumed in block 350, the bytecode 170 is recursive, the API of the present invention specifies an appropriate PPA subroutine 360 configured for the environment of the RBC 230, whereby the present represented by the RBC 230 Machine functions can access registers in CPU 110 that contain variable values necessary to execute the subroutine. Required variables can include pointers to constant pools, stacks, native and program code. In block 362, the PPA subroutine 360 specified by the API executes the preamble before the CPU begins processing the native operations corresponding to the RBC 230 in block 364. Processing of the native machine continues until a native context access function is encountered in block 364, which restarts the VMI. In block 365, the parameters of the VMI are changed to process method 220 until the RETURN bytecode causes any remaining native processing to resume (block 366). Encountering another RETURN bytecode during native processing then shifts control back to the PPA subroutine for which the postamble is executed in block 367, and, after completion of execution of the PPA subroutine 360, In block 368, control is returned to the VMI for processing according to the new parameters. The address of the appropriate PPA subroutine 360 is stored in the table 140 and corresponds to the software trap of the bytecode 170 configured to handle recursion. The preamble is executed before the native operation invoked by the RBC 230 (native processing) is executed. If a standard preamble is associated with a native function called by the RBC 230, then the preamble of the present invention is executed to either replace or modify the standard preamble associated with the native function. The postamble is executed after executing a native function called by the RBC 230. Similarly, the postamble of the present invention is executed after a C RETURN statement in an RBC native function to either replace or modify the standard postamble associated with the native function called by the RBC (if a standard postamble exists). sync code).

In accordance with an aspect of an exemplary embodiment of the present invention, the preamble writes a value to a variable representing some important pointer, such as a stack pointer, thereby enabling native functions called by the RBC 230 to access the pointer . For example, to provide access to the environment of native functions called by RBC 230, several functions are defined:

void*vmi_bcc(void*jfp);

void*vmi_object(void*jfp);

void*vmi_jsp(void*jfp);

void*vmi_cpd(void*jfp);

void*vmi_cpt(void*jfp);

void*vmi_bcc(void*jfp);

Similarly, the following function gives access to a constant pool:

<t>vmi_cpdEntry(void *jfp, unsigned n, <t>)

unsigned char vmi_cptEntry(void*jfp, unsigned n)

The following functions give access to the current and next bytecode 170:

unsigned char vmi_bc(void*jfp, n)

unsigned char vmi_s hortPar(void* jfp, n)

unsigned char vmi_3bytePar(void* jfp, n)

unsigned char vmi_wordPar(void*jfp, n)

The following functions are used to access the Java ^TM stack:

<t>vmi_stkEntry(void *jfp, n, <t>)

Referring now to FIG. 4, the active translation (Java bytecode processing) function of the VMI is specified by the Java Virtual Machine (JVM) standard. Figure 4 shows a hypothetical bytecode processing timeline, where the intervals T0-T12 represent periods of arbitrary time that are not necessarily equal. During interval T0, the VMI translates bytecodes using the API of the present invention as an interface until a recursive bytecode (RBC) 230 is encountered. Cross-referencing the hypothetical diagram in Figure 2, the VMI processes bytecodes B0 through B2 before encountering Bn. When the appropriate RBC software trap (indicated by the API) is identified and the corresponding PPA subroutine is executed, the RBC 230(Bn) causes control to be passed to the native process in interval T1. In interval T2 to T10, the software trap executes a native function called by RBC 230, thereby accessing (in interval T4) the environment initialized by the preamble. For example, the processing cycles of intervals T3 and T4 (dedicated to native operations of the RBC 230 and calls to environment access functions) are repeated in intervals T5 and T6 as needed. The native function finally (possibly after thousands of native execution cycles) yields the native environment access function, which restarts the VMI at interval T7. VMI actively processes the bytecodes (presumably bytecodes Bo to Br) for the newly invoked method until it encounters a RETURN bytecode (Bs) at interval T7, which returns control to the native function deal with. In interval T8, control is returned entirely from VMI 120 to native processing, either by VMI 120 hardware, or by software (implemented via API and via code such as the C programming language RETURN statement). Native processing continues in interval T10 when another C RETURN statement transfers control to the PPA subroutine so that the postamble is executed in interval T11. After control is returned to the VMI 120 (at assumed bytecode Bn ₊₁ ) in time interval T12, the postamble of the present invention writes the variable values modified by the RBC subroutine back to the CPU containing these variables register. According to another embodiment shown in FIG. 5, the preamble and postamble may be executed to implement the environment changes required to process the newly invoked method (exemplary bytecodes Bo to Bs), e.g., change native processing of the first preamble before the start of interval T1, the first postamble before the method is processed in T9 to T11, another preamble in interval T12 after execution of the method, and The last postamble in interval T16 after local processing is complete.

Referring again to FIG. 3 , in block 368 , the PPA subroutine specified by the API is also configured to begin resuming translation in VMI 120 of sequence 210 of bytecode 170 . Either through the VMI 120 or through an API implementation, and either in hardware or in software, control is returned entirely from the VMI 120 to native processing. The software implementation of this recovery routine is through code such as the C programming language RETURN statement, which is usually included in native functions. After returning from native processing, the context is destroyed by, for example, vmi_freeFrame so that control can be passed back to the VMI 120. The destruction of the context frees an area of the CPU 110 configured to handle the context of the RBC 230, and translates the VMI 120 back to a position in the sequence 210 of the bytecode 170, for example (but not necessarily) to the position immediately following Position after the most recently translated RBC 230.

When control is returned to the VMI 120 in block 310, the virtual machine counter is incremented and the VMI 120 fetches the next bytecode 170. Thus, translation by the VMI 120 will continue until another RBC 230 is encountered or the translation process terminates (e.g., the VMI encounters another complex bytecode, or runs within the bytecode for processing).

In view of the foregoing, it will be appreciated that the present invention provides a system and method for supporting a software trap method of processing virtual machine instructions to facilitate the implementation of a method for accurately and efficiently processing recursive virtual machine instructions. Furthermore, it should still be understood that the foregoing relates only to exemplary embodiments of the invention and that many changes may be made therein without departing from the spirit and scope of the invention as defined in the following claims.

Claims (12)

1. method of handling virtual machine instructions comprises:

Initiation parameter is so that identification has the subclass of the virtual machine instructions of special characteristic set;

A collection of described virtual machine instructions is translated as can be by the native instructions of processor execution, till the member in running into the described virtual machine instructions subclass that identifies;

In case run into a member in the described virtual machine instructions subclass that identifies, just hang up translation to described batch of virtual machine instructions;

Realize interface, wherein said interface has been stipulated the set of this machine processor instruction, this instruction set can:

Before this machine processor instruction that the described member who carries out by the described virtual machine instructions subclass that identifies represents, carry out preamble;

This machine of retrieval function from the corresponding processor of representing with described member of instruction by the described virtual machine instructions subclass that identifies;

The native instructions that execution retrieves;

After the native instructions that the described member who carries out by the described virtual machine instructions subclass that identifies represents, carry out postamble; And

The translation of recovery in the virtual machine of described batch of virtual machine instructions wherein, carried out and continued till another member who runs into the described virtual machine instructions subclass that identifies; And

Carry out described machine processor instruction set.

2. the method for claim 1 further comprises:

Before the native instructions of the method for formation that execution retrieves, carry out postamble, wherein, described postamble comprises native instructions, and described native instructions is used to revise the interior variate-value of register of processor, so that realize carrying out the needed environment change of this method; And

Carry out preamble after the native instructions of the method for formation that execution retrieves, wherein, described preamble comprises the register of value from processor is write in the variable that can be visited by the native instructions of carrying out after carrying out this method.

3. the method for claim 1, wherein described preamble and described postamble are produced by virtual machine.

4. the method for claim 1, wherein described preamble and described postamble retrieve from processor storage.

5. the method for claim 1, wherein described preamble comprises the native instructions that the register of value from processor is write variable, and wherein, described variable can be by the instruction access of being represented by the described virtual machine instructions subclass that identifies.

6. the method for claim 1, wherein, described postamble comprises native instructions, and described native instructions is modified to the variate-value in the register of processor in the register of processor according to the instruction of being represented by the described virtual machine instructions subclass that identifies.

7. the method for claim 1, wherein described preamble and described postamble are replaced the conflict instruction that is associated with the described member of the described virtual machine instructions subclass that identifies.

8. the method for claim 1, wherein described preamble and described postamble are revised the conflict instruction that is associated with the described member of the described virtual machine instructions subclass that identifies.

9. the method for claim 1 further comprises beginning to recover subroutine, and wherein, described recovery subroutine comprises:

Register in the processor that release was visited by preamble and postamble; And

Guide the place location restore translation of virtual machine in described batch of virtual machine instructions.

10. method of handling virtual machine instructions comprises:

Environment in the configuration CPU (central processing unit);

Realization is used for the interface of this machine of regulation processor instruction set, and described machine processor instruction set comprises:

Before carrying out this machine processor instruction of representing by described virtual machine instructions, carry out preamble;

From with the corresponding processor of the instruction of representing by described virtual machine instructions retrieval this machine function;

The native instructions that execution retrieves;

After carrying out the native instructions of representing by described virtual machine instructions, carry out postamble; And

Discharge the environment that is disposed; And

Carry out described machine processor instruction set.

11. an equipment that is used to handle virtual machine instructions comprises:

Processor (110), it has the native instructions collection, and is configured to carry out native instructions;

Command memory (150), it is configured to the storage virtual machine instruction;

Pretreater (120), wherein, described pretreater (120) is a virtual machine, it is configured to from command memory (150) to take out virtual machine instructions, and the virtual machine instructions that is configured to take out is translated as the native instructions that can be carried out by processor; And

Interface between described command memory (150) and the described processor (110), it is configured to start a subroutine, this subroutine writes register with the value of the variable that the instruction that can be represented by virtual machine instructions in the described processor unit (100) is visited, send this loom routine call, revise the value of described variable and control is returned to described pretreater according to described virtual machine instructions corresponding to the instruction of representing by virtual machine instructions.

12. the method for this machine processor subroutine that is used to carry out called by virtual machine instructions comprises:

Carried out the preamble set of native instructions before carrying out the subroutine of being called, wherein, described preamble is configured to value is write from the register of processor can be by the variable of the subroutine visit of being called; And

Carry out the postamble set of native instructions after carrying out the subroutine of being called, wherein, described postamble is configured to according to the variate-value in the register of the subroutine modification processor that is called.

Images