KR100513138B1 - A processor for executing instruction sets received from a network or from a local memory - Google Patents

Abstract

The dual instruction set processor of the present invention can interpret and execute both code received from the network and other code supplied from local memory, so that two different types from two different sources can be executed at maximum efficiency, as described above. Computer systems with communication interface devices, such as modems for connection to a network such as the Internet or an intranet, local memory and dual instruction set processors, have a JAVA code from the network and a locally stored or on-network but reliable environment or authentication. It can be optimized to run non-JAVA code in a built-in environment.

Description

PROCESSOR FOR EXECUTING INSTRUCTION SETS RECEIVED FROM A NETWORK OR FROM A LOCAL MEMORY}

See Appendix I

The opening portion of this patent publication, including the appendix I, the JAVA Virtual Machine Specification and Appendix A, includes content for copyright protection purposes. The copyright holder has no objection, even if the patent publication or the publication is copied, because the patent office has a patent file or record, otherwise the copyright holder has all copyrights.

TECHNICAL FIELD The present invention relates to computers and information systems, and more particularly, to improved processors and computer systems for executing instruction sets from both local memory and networks such as the Internet or intranets.

Many individuals and organizations in the computer and telecommunications industry recommend the Internet, a rapidly growing market worldwide. In the 1990s, the number of Internet users has grown exponentially. In June 1995, approximately 6,642,000 hosts were connected to the Internet, an increase from approximately 4,852,000 hosts in January 1995. The number of hosts is increasing by 75% every year. There are about 120,000 networks and more than 27,000 web servers among the hosts. The number of web servers is doubling every 53 days.

With more than 1,000,000 active Internet users, more than 12,505 Usenet newsgroups, and more than 10,000,000 Usenet readers in July 1995, the Internet will explode into a large market for a vast and diverse set of information and multimedia services.

In addition, many organizations and companies over the Internet or public carrier networks are turning their internal information systems into intranets as a means of more efficient distribution of information within dedicated networks or companies. The basic infrastructure for an intranet is an internal network connecting servers and desktops, which may or may not be connected to the Internet through a firewall. These intranets provide services to the desktop via standard open network protocols that are well established within the enterprise. Intranets benefit companies that use intranets by simplifying internal information management and improving internal communications using the browser paradigm. Integrating Internet technology into existing systems and the company's corporate infrastructure will impact current technology investments for those employing intranets. As noted above, intranets and the Internet are closely related, intranets are used for secure business communication, and the Internet is used for external transactions between the business and other areas. For the purposes of this application, the term "network" includes the Internet and an intranet. However, the difference between the Internet and intranets depends on where they are available.

In the 1990s, Sun Microsystems programmers used a common programming language. This language was named JAVA programming language. JAVA is a trademark of Sun Microsystems in Mountain View, CA. The JAVA programming language is due to a programming effort that was originally intended to be coded as a C ++ programming language, and as a result the JAVA programming language is compatible with the C ++ programming language. However, the JAVA programming language is a simple, object-oriented, distributed, interpreted but high performance, powerful but secure, secure, active, intermediate, compatible, multithreaded language.

The JAVA programming language has been selected as the programming language for the Internet by many large hardware and software companies licensed from Sun Microsystems. The JAVA programming language and environment are designed to solve many problems in current programming practice. The JAVA programming language omits the confusing, incomprehensible, and underused features of the C ++ programming language. These omitted features mainly include operator overload, multiple inheritance, and extensive automatic enforcement. The JAVA programming language includes automatic dance information collection that simplifies the task of programming because you no longer need to allocate or free memory as in the C programming language. The JAVA programming language restricts the use of pointers as defined in the C programming language and instead has an exact array whose array bounds are explicitly checked, thereby eliminating vulnerabilities to many viruses and annoying bugs. The JAVA programming language includes an object-C interface and a special exception handler.

The JAVA programming language has an extensive library of routines for easy copying with the Transmission Control Protocol based on Internet protocol (TCP / IP) protocol, Hypertext Transfer Protocol (HTTP), and File Transfer Protocol (FTP). JAVA programming language tends to be used in networked / distributed environments. JAVA programming language allows the construction of a virus-free and tamper-free system. Authentication techniques are based on public-key cryptography.

The present invention relates to a processor designed to decode and execute virtual machine instructions (computer platform independent instructions), such as instruction sets for virtual computing machine architectures received from a network. However, the processor also has the ability to decrypt and execute a second set of computer instructions supplied from local memory or the like. The second set of computer instructions is for a computer processor architecture different from the virtual computing machine architecture. The concept of a processor capable of executing two instruction sets from two different sources allows the processor to have maximum efficiency in running applications that perform multiple functions.

The present invention includes a communication interface device such as a processor, a local memory, and a modem for connection to a network such as the Internet or an intranet. Finally, the present invention provides the compiled code with or without security features, such as array boundary validation, depending on whether the compiled code is run and executed over a network or retrieved and executed from a trusted environment such as local memory. Includes a way to compile an application written with a JAVA source code program that allows code to run.

In one embodiment, the virtual machine instructions are processed by a translation unit. The translation unit may be configured to convert each virtual machine instruction into a native instruction, primitive instructions or SPARC series from Sun Microsystems, Alpha from Digital Technology, MIPS series from Silicon Graphics, Motorola / IBM / Apple Power PC series, or Intel x86 and iA4. Converts to microcode routines for execution units of conventional processors of the processor family. Thus, the virtual machine instructions of the first example are translated into native instructions for a RISC processor, the second example is translated into native instructions for a CISC processor, and the third example is translated into a very long instruction word (VLIW) processor. In each of the above examples, the primitive instructions from the translation unit are decoded by a conventional decode unit and the decoded primitive instructions are executed by a conventional execution unit. Optionally, if the translation unit provides a microcode routine for a virtual machine instruction or a set of virtual machine instructions, the instruction decoder is bypassed and the microcode routine will be executed immediately by a conventional execution unit.

In another embodiment, the processor of the present invention is configured for making a communication connection to a network and local memory. The first instruction decoder of the processor is configured to decode a plurality of first instructions in the first instruction set. The second instruction decoder of the processor is configured to decode a plurality of second instructions in the second instruction set. The second instruction set and the first instruction set are different. The instruction execution unit of this processor is configured to execute a plurality of first instructions decoded by the first instruction decoder and to execute by the plurality of second instructions decoded by the second instruction decoder.

The first instruction decoder is configured to decode a set mode instruction in the first instruction set. In response to this set mode command, the next command to the set mode command is passed to the second command decoder.

In one embodiment, each of the first instruction sets is a virtual machine instruction. Virtual machine instructions contain opcodes. Moreover, in this embodiment, the first execution is a stack-based execution unit.

As will be described in more detail below, applications written in the JAVA programming language are particularly well suited for generating sources of executable code within the type of virtual machine instructions, and are executed by processors such as hardware processor 100 (FIG. 1). Can be transmitted over a network such as the Internet or an intranet. However, some applications require a processor that has the ability to decode and execute instructions provided, for example, on local memory or even over a network rather than virtual machine instructions.

In one embodiment, hardware processor 100 is not used to execute the virtual machine instructions. Rather, conventional microprocessor architectures such as the SPARC family of Sun Microsystems architecture, Alpha from Digital Technology, MIPS architecture from Silicon Graphics, Motorola / IBM / Apple Power PC architectures, or Intel x86 and iA4 architectures, along with translation units Used.

In particular, the translation unit is added to a conventional microprocessor to enable this conventional microprocessor to execute virtual machine instructions and native instructions for the microprocessor, thereby making the conventional microprocessor a dual instruction set microprocessor. Of course, additional microcode may be required in conventional processors to support the execution of the translated instructions and to support the environment required by the virtual machine instructions. The particular addition required depends on the set of virtual machine instructions and the choice of conventional processor architecture.

As will be described in more detail below, the translation unit translates the virtual machine instructions into instructions within a set of primitive instructions of a conventional microprocessor that are directly executed alternately by the conventional microprocessor. However, some virtual machine instructions may be translated into microcode executed alternately by the conventional microprocessor. Thus, as will be described in more detail below, the dual instruction set processor of the present invention can execute two different instruction sets from two different sources, such as network and local memory. In this specification, a set of instructions refers to instructions for a particular type of computer processor architecture.

In another embodiment, the dual instruction set processor of the present invention includes a virtual machine instruction processor such as a hardware processor 100 and a second processor for executing instructions different from the virtual machine instructions. This dual instruction set processor has several advantages. For example, the number of instructions available is improved. In particular, based on the bytecode limitation, the number of instructions in the JAVA virtual machine instruction set is limited to 256 instructions or less. This limit is not optimal for some applications. Since the dual instruction set processor has a second instruction set, the application can call the instruction set in the second instruction set if more functionality is required than that provided by the virtual machine instruction set, Or completely written into the second instruction set.

In particular, the set of JAVA virtual machine instructions may be extended by including native instructions for the second processor in the datastream. Prior to executing the primitive instruction in the datastream, the mode of the dual instruction set processor is set to execute the instruction on the second processor and the primitive instruction in the datastream executed by the second processor. After execution of the primitive instruction is completed by the second processor, the mode of the dual instruction set processor returns to the mode of directly executing the virtual machine instruction. In this way, the instruction space of the virtual machine is enhanced by effectively mapping the primitive instructions of the second processor to the instruction space of the virtual machine.

In addition, the JAVA Virtual Machine Specification strictly enforces security checks, such as checking the array boundaries, to ensure that viruses and other software problems are not transmitted from the network to the user's computer system. However, in some applications, such security checks are cumbersome and waste unnecessary time. For such an application, an application of multimedia libraries or other executable code can be loaded from local memory or other trusted environment. When executable code is loaded from the trusted environment, the security check is not used and performance is improved.

Optionally, as described in more detail below, two versions of an application written in the JAVA programming language can be compiled to provide two different virtual machine applications. The first virtual machine application is used in an insecure environment, such as a network for moving information over a public carrier, and includes all of the secure features provided by the JAVA virtual machine specification. The second virtual machine application is used in a secure environment, such as a local network or a single computer, to run faster because it does not include all or some of the secure features that do not include code authentication.

As will be described in more detail below, the dual instruction set processor of the present invention automatically routes instructions to appropriate execution units based on information in instructions provided to the processor. Before considering the dual instruction set processor in detail, an embodiment of the hardware processor 100 will be described below, and then the dual instruction of the present invention comprising the same processor executing the hardware processor 100 or virtual machine instructions. A more detailed description of the set processor is provided.

1 is a diagram illustrating an embodiment of a virtual machine instruction hardware processor 100 (hereinafter referred to as hardware processor 100), which may be used as a dual instruction processor in accordance with the present invention, and directly directs virtual machine instructions that are independent of the processor architecture. Run The performance of the hardware processor 100 executing JAVA virtual machine instructions is either Intel's PENTIUM microprocessor or Sun Microsystems' ULTRASPARC processor (ULTRASPARK is a registered trademark of Sun Microsystems, Inc., Mountain View, California, PENTIUM is Sunny, California It is better, cheaper, and consumes less power than a software JAVA interpreter (such as Intel's trademark in Vale) or a high-end CPU that decodes the same virtual machine instructions with a JAVA real-time compiler. As a result, the hardware processor 100 is more suitable for mobile applications. The hardware processor 100 provides similar advantages for other virtual machine stack-based architectures as well as for virtual machines that use features such as garbage collection, thread synchronization, and the like.

With this feature, a system based on hardware processor 100 provides an attractive price point for performance characteristics, if not the best performance, compared to an optional virtual machine execution environment that includes a software interpreter and a real-time compiler. Nevertheless, the present invention is not limited to virtual machine hardware processor embodiments, and emulates a JAVA virtual machine as a software interpreter, or JAVA virtual machine instructions (batch or just-in-time). Appropriate stack-based or implementations, including hardware that implements JAVA virtual machines in native code, or in microcode, directly in silicon, or any combination thereof. Non-stack-based machine implementations.

Considering the price for the performance characteristic, the hardware processor 100 has an advantage that 250 kilobytes to 500 kilobytes (Kbytes) of storage devices such as RAM or ROM memory required by a software interpreter are removed.

According to the simulation of the hardware processor 100 of the present application, the speed at which the hardware processor 100 executes the virtual machine instructions is the same virtual machine while running several applications on the Pentium processor clocked at the same clock rate as the hardware processor 100. It shows that it is 20 times faster than the software interpreter executing the command. Another simulation of the hardware processor 100 executes virtual machine instructions five times faster than a real-time compiler running on a PENTIUM processor where the hardware processor 100 runs at the same clock rate as the hardware processor 100 and executes the same virtual machine instructions. Shows.

In the cost environment of memory required for the software virtual machine instruction interpreter, the hardware processor 100 has an advantage. Such applications include, for example, Internet chips for network applications, cellular telephone processors, other telecommunication integrated circuits, or other low-power, low-cost applications that are embedded and mobile devices in the processor.

As used herein, a virtual machine is a theoretical computing machine that has a set of instructions like a real computing device and uses various memory regions. The virtual machine specification defines a processor architecture independent virtual machine instruction set that is executed by a virtual machine implementation, such as hardware processor 100. Each virtual machine command defines a special operation to be executed. The virtual computing machine does not need to understand the underlying language of the virtual machine or the computer language used to generate the virtual machine instructions. You just need to understand the specific file format for the virtual machine instructions.

In one embodiment, the virtual machine command is a JAVA virtual machine command. Each JAVA virtual machine command includes one or more bytes that encode command confirmation information, operands, and other necessary information. Appendix I, which is described herein by reference, includes an illustrative set of JAVA virtual machine instructions. The particular set of virtual machine instructions used is not an important feature of the present invention. Those skilled in the art in view of the virtual machine instructions in Appendix I and the foregoing description are capable of modifying the invention for a special set of virtual machine instructions or for switching to the JAVA virtual machine specification.

JAVA compiler running on a computer platform JAVAC (FIG. 2) is an application written in JAVA computer language in an architecture-neutral object file format that encodes a compiled instruction sequence 203 containing a set of instructions compiled according to a JAVA virtual machine description. Convert 201. However, for the present invention, only source of relationship information and virtual machine instructions is needed. In the present method or technique used to generate the relationship information and the source of the virtual machine instruction, the relevant information is not important to the present invention.

The compiled instruction sequence 203 can be executed on the hardware processor 100 as well as on a computer platform implementing JAVA virtual machine usage such as a software interpreter or a timely compiler. However, as noted above, the hardware processor 100 provides significant execution advantages over software implementation.

In this embodiment, hardware processor 100 (FIG. 1) processes JAVA virtual machine instructions that include bytecode. The hardware processor 100 executes most of the bytecode directly, as described more precisely below. However, some bytecode execution is done through microcode.

A method for selecting virtual machine instructions executed directly by hardware processor 100 is described herein as an example. Thirty percent of JAVA virtual machine instructions are true hardware translations, and the instructions implemented in this method include constant load and simple stack operation. The next 50% of the virtual machine instructions are mostly executed in hardware, but require some firmware assistance in hardware, not entirely, and these include array instructions and stack-based operations. The next 10% of JAVA virtual machine instructions are implemented in hardware, but not only require special firmware support, but they also include function returns and function calls. The remaining 10% of JAVA virtual machine instructions are not supported in hardware, but are supported by microcode and / or firmware traps, which include functions such as exception handlers. Firmware here means that the microcode is stored in the ROM when execution controls the operation of the hardware processor 100.

In one embodiment, hardware processor 100 includes an I / O bus and memory interface unit 110, an instruction cache unit 120 including instruction cache 125, an instruction decode unit 130, a unified execution unit ( 140, stack management unit 150 including stack cache 155, data cache unit 160 including data cache 165, program counter and trap control logic 170. Each of these units is described in more detail below.

In addition, as shown in FIG. 1, each unit includes various elements. In order to avoid and clarify the chaos from the present invention, the relationship between the elements in each unit is not shown in FIG. However, in the following description, those skilled in the art will be able to understand the coupling and interrelationships between the elements between the units and the various units.

The pipeline stage is implemented using the unit shown in FIG. 1, including the patch, decode, execute, and write-back stages. Preferably additional steps are provided to the hardware processor 100 for memory access or exception resolution.

3 is a diagram of a four stage pipeline for execution of instructions in an embodiment of the processor 100. In patch step 301 virtual machine instructions are located in the command buffer 124 (FIG. 1) and patched. The virtual machine instructions are patched from either (i) a fixed size cache line from the instruction cache 125 or (ii) internal memory.

For patches, except for the command table switch and the lookup switch (see Appendix I), each virtual machine command is between 1 and 5 bytes long. So to keep this simple, at least 40 bytes are needed to ensure that all of the given instructions are kept in the patch.

Alternative embodiments always patch a predetermined number of bytes, such as 4 bytes, beginning with an opcode. This is sufficient for 95% of JAVA virtual machine commands (see Appendix I). For instructions that require more than 3 bytes of operand, another cycle of the front end is allowed if 4 bytes are fetched. In that case, instruction execution may begin with a patched first operand patch even if the entire set of operands is not yet available.

In decode step 302 (FIG. 3), the virtual machine instructions preceding the instruction buffer 124 (FIG. 1) are decoded and possibly instruction folding is performed. Stack cache 155 accesses virtual machine instructions only when needed. The register optop that holds the pointer optop to the top of the stack 400 (FIGS. 4A and 4B) is also updated in the decode step 302 (FIG. 3).

Here, conventionally, register values and registers are assigned the same numbers. Moreover, the use of registers to store pointers in the following discussion is just one embodiment. According to a particular implementation of the invention, the pointer is implemented using other embodiments known to those skilled in the art, software pointers, software counters, hardware counters or hardware registers. The particular implementation chosen is not critical to the invention and is typically made based on price for performance tradeoffs.

In execution step 303, virtual machine instructions are executed for one or more cycles. In general, in execution step 303, the ALU of integer unit 142 (FIG. 1) is used to calculate the address of the storage or loading from data cache unit (DCU) 160, or for an arithmetic operation. If necessary, the traps are ordered and selected at the end of execution of execution step 303 (FIG. 3). For the control flow command, the branch address is calculated at execution step 303 as well as the state the branch is dependent on.

The cache step 304 is a non-pipelined step. Data cache 165 (FIG. 1) is accessed if necessary during execution step 303 (FIG. 3). The reason why step 304 is non-pipeline is that hardware processor 100 is a stack based device. Therefore, the command following the load is almost always dependent on the value returned by the load. Thus in this embodiment the pipeline is fixed in one cycle for data cache access. This reduces the die area adopted by the pipeline stage and pipeline for bypass and special registers.

Write-back stage 305 is the final stage of the pipeline. The data calculated in step 305 is written back to the stack cache 155.

The hardware processor 100 of this embodiment directly implements the stack 400 (FIG. 4A) supporting the JAVA virtual machine stack infrastructure (see Appendix I). 64 entries on the stack 400 are included on the stack cache 155 in the stack management unit 150. Some entries in stack 400 may be copied onto stack cache 155. Operation on the data is performed through the stack cache 155.

Stack 400 of hardware processor 100 is primarily used as a repository of information about methods. At any location over time, the hardware processor 100 executes a single method. Each method has the same memory space as the method frame on stack 400 and is allocated for the execution environment structure, operand stack, and set of local variables.

A new method frame, that is, method frame 2 410, is allocated by the hardware processor 100 on the method invocation in execution step 303 (FIG. 3) and becomes the current frame, such as the frame of the current method. The current frame 410 (FIG. 4A) as well as other method frames may include some or all of the following six entries, depending on the various method call situations.

Object reference;

Incoming argument;

Local variables;

The method context of the caller;

Operand stack; And

Return value from the method.

In FIG. 4A, object references, incoming arguments, and local variables are included in the argument and local variable regions 421. The caller's method background is included in the execution environment 422, sometimes referred to as the frame state, followed by the method call command followed by the return program counter value 431, the address of the virtual machine command, such as a JAVA optop, of the calling method. The return frame 432, which is the location of the frame, the return constant pool pointer 433, which is a pointer to the constant pool table of the calling method, the current method vector 434, which is the base address of the current method vector table, and the address of the current method monitor. It includes the current monitor address 435 in turn.

The object reference is an indirect pointer to an object store that represents the object targeted for the method call. JAVA compiler JAVAC (see FIG. 2) generates an instruction to push the pointer onto operand stack 423 before generating a call instruction. The object reference is accessible as local variable zero while the method is running. The indirect pointer is not valid for a static method call when there is no target object defined for the static method call.

The list of incoming arguments sends information from the calling method to the called method. Like object references, incoming arguments are pushed onto stack 400 by JAVA compiler generated instructions and may be accessed as local variables. JAVA compiler JAVAC (see FIG. 2) statistically generates a list of arguments for the current method 410 (FIG. 4A), and the hardware processor 100 determines the number of arguments from the list. When an object reference appears in a frame for a non-static method call, the first argument is accessible as one of the local variables. In a static method call, the first argument is a local variable zero.

In a 64-bit argument, the upper 32 bits, or 32 most significant bits, of the 64-bit entities, as well as the 64-bit entities in general, are placed on top of the stack 400, ie pushed last on the stack. For example, if a 64-bit entity is located at the top of the stack 400, the upper 32-bit portion of the 64-bit entity is at the top of the stack, and the lower 32-bit portion of the 64-bit entity is immediately adjacent to the top of the stack 400. It is in a storage location.

The local variable area of the stack 400 (FIG. 4A) for the current method 410 represents the temporary variable storage space allocated and remains valid during the method 410 call. The JAVA compiler JAVAC (FIG. 2) statistically determines the number of local variables required, and the hardware processor 100 allocates temporary variable storage space accordingly.

When the method is executed on the hardware processor 100, the local variable is generally in the stack cache 155, addressed as an offset from the pointer VARS (FIGS. 1 and 4A), and the VARS zeros the position of the local variable. To point. Instructions are provided to load local variable values into operand stack 423 and store the values from operand stack into local variable area 421.

The information in execution environment 422 includes the caller's method background. If a new frame is designed for the current method, hardware processor 100 pushes the caller method background to the newly assigned frame 410 and then uses the information to recover the caller's method background before returning. The pointer FRAME (FIGS. 1 and 4A) is a pointer to the execution environment of the current method. In an embodiment, each register in register set 144 (FIG. 1) is 32 bits wide.

Operand stack 423 is allocated to support the execution of virtual machine instructions within the current method. The program counter register PC (Fig. 1) contains the address of the next instruction to be executed, such as an opcode. The location on operand stack 423 (FIG. 4A) is used to store operands of virtual machine instructions that provide both source and target storage locations for instruction execution. The size of the operand stack 423 is statistically determined by the JAVA compiler JAVAC (FIG. 2), and the hardware processor 100 allocates space for the operand stack 423 accordingly. The register optops (FIGS. 1 and 4A) hold a pointer to the top of the operand stack 423.

The invoked method can return the result of its execution to the top of the caller's stack so that the caller can access the return value with the operand stack reference. The return value is placed in the area where the object reference or argument is pushed before the method executes.

Simulation results of the JAVA virtual machine show that method calls consume a major portion of execution time (20-40%). Providing such interesting targets to accelerate the execution of virtual machine instructions, hardware support for method execution is included in hardware processor 100 as described more fully below.

The start of the newly called method's stack frame, that is, the object reference and arguments passed by the caller, are already stored in stack 400 because the object reference and incoming arguments come from the top of the caller's stack. As noted above, following these items on the stack 400, local variables are loaded, and the execution environment is loaded.

One way to speed up this process is for the hardware processor 100 to load the execution environment in the background, indicating that it has been loaded so far, such as simple 1-bit scoreboarding. The hardware processor 100 attempts to execute the bytecode of the called method as soon as possible even if the stack 400 is not fully loaded. If access is made to a variable that has already been loaded, then the stack 400's load and execution overlap, otherwise a hardware interlock occurs and the hardware processor 100 only waits for the variable (s) in the execution environment to be loaded.

4B illustrates another method for accelerating method calls. Instead of storing the entire method frame on the stack 400, the execution environment of each method frame is stored separately from the operand stack and local variable regions of the method frame. Thus, in this embodiment, the stack 400B includes a modified method frame, such as a modified method frame 410B having only a local variable area 421 and an operand stack 423. The execution environment 422 of the method frame is stored in the execution environment memory 440. Storing the execution environment in the execution environment memory 440 reduces the amount of data in the stack cache 155. Therefore, the size of the stack cache 155 can be reduced. In addition, execution environment memory 440 and stack cache 155 may be accessed simultaneously. Thus method execution can be accelerated by loading or storing the execution environment concurrently with loading or storing data into the stack 400B.

In one embodiment of the stack management unit 150, the memory structure of the execution environment memory 440 is also a stack. As the modified method frame is pushed to stack 400B through stack cache 155, the corresponding execution environment is pushed to execution environment memory 440. For example, as shown in FIG. 4B, since modified method frames 0-2 are on the stack 400B, the execution environment EEs 0-2 are each stored in the execution environment memory circuit 440. Stored.

To further improve method execution, execution environment caches can be added to improve the speed of preserving and retrieving the execution environment during method invocations. The structure described below in more detail below for the stack cache 155, the dribble management unit 151, and the stack control unit 152 for caching the stack 400 may be applied to cache the execution environment memory 440. .

4C illustrates an embodiment of the stack management unit 150 modified to support both stack 400b and execution environment memory 440. In particular, the embodiment of stack management unit 150 in FIG. 4C adds execution environment stack cache 450, execution environment dribble management unit 460, and execution environment stack control unit 470. In general, execution dribble management unit 460 transfers the entire execution environment between execution environment cache 450 and execution environment memory 440 during a spill or fill operation.

I / O Bus and Memory Interface Unit

Memory interface unit 110 (FIG. 1), which is sometimes referred to as I / O bus and interface unit 110, includes an external memory and optionally includes a memory storage device on a die that is identical to hardware processor 100. Implement an interface between the hardware processor 100 and a memory hierarchy that may include an interface. In this embodiment, I / O controller 111 interfaces with external I / O devices, and memory controller 112 interfaces with external memory. In this specification, the external memory refers to a memory external to the hardware processor 100. However, the external memory may be included on the same die as the hardware processor 100, may be external to the die including the hardware processor 100, or may include both on and off die portions.

In another embodiment, the request to the I / O device is through a memory controller 112 that maintains an address map of the entire system, including the hardware processor 100. In the memory bus of this embodiment, the hardware processor 100 is the only master and does not need to mediate using the memory bus.

Therefore, alternatives to the I / O bus and the input / output bus that interfaces with the memory interface unit 110 include supporting memory map designs that provide direct support of PCI, PCMCIA, or other standard buses. Fast graphics (w / VIS or other techniques) may optionally be included on the die with hardware processor 100.

I / O bus and memory interface unit 110 generates read and write requests to external memory. In particular, the interface unit 110 provides interfaces to the external memory for the instruction cache and data cache controllers 121 and 161. The interface unit 110 includes arbitration logic for external requests from the command cache controller 121 and the data cache controller 161 to access the external memory, and in response to the request, read or write requests to the external memory on the memory bus. Initialize Requests from the data cache controller 161 are always processed at a higher priority with respect to requests from the command cache controller 121.

The interface unit 110 provides an acknowledgment signal to the command cache controller 121 or the data cache controller 161 in a read cycle that the requesting controller can latch data. In a write cycle, an acknowledgment signal from the interface unit 110 is used for flow control so that the requesting command cache controller 121 or the data cache controller 161 does not generate a new request if there is one outstanding. The interface unit 110 also handles errors generated in the external memory on the memory bus.

Instruction Cache Unit

Instruction cache unit (ICU) 120 (FIG. 1) fetches virtual machine instructions from instruction cache 125 and provides instructions to instruction decode unit 130. In this embodiment, in the case of an instruction cache hit, the instruction cache controller 121 in one cycle until the integer execution unit (IEU) described below in more detail from the instruction cache 125 is ready to process the instruction. The command is sent to the command buffer 124 where the command is held. This separates the rest of pipeline 300 in hardware processor 100 from patch step 301. If it is not desirable to incur the complexity of supporting the instruction buffer type of batch, any one instruction register is sufficient for most objects. However, instruction patching, caching, and buffering must provide sufficient instruction bandwidth to support instruction folding as described below.

The front end of the hardware processor 100 is widely separated from the rest of the hardware processor 100. Ideally, one instruction per cycle is emitted to the execution pipeline.

The instructions are aligned at any 8-bit boundary by the byte aligner circuit 122 in response to the signal from the instruction decode unit 130. Thus, the front end of the hardware processor 100 fully handles patching from any byte position. The hardware processor 100 also handles the problem of instructions across multiple cache lines in the cache 125. In this case, since the opcode is the first byte, the design can tolerate the extra cycle of patch potential for the operand. Thus, a very simple disconnection between patch and execution of bytecode is possible.

In the case of an instruction cache miss, the instruction cache controller 121 generates an external memory request for the missed instruction to the I / O bus and memory interface unit 110. If the instruction buffer 124 is empty or nearly empty, then if there is an instruction cache miss, the instruction decode unit 130 is stopped, ie the pipeline is stopped. In particular, the instruction cache controller 121 generates a stop signal when a cache miss is used in accordance with the instruction buffer empty signal to determine whether to stop the pipeline 300. The instruction cache 125 may be invalidated to adjust self-correcting code, for example the instruction cache controller 121 may invalidate certain lines in the instruction cache 125.

Thus, the instruction cache controller 121 determines the next instruction to be patched, i.e., instructions in the instruction cache 125 that need to be accessed, and addresses, data, and control signals for tag RAM and data in the instruction cache 125. Create In the case of a cache hit, four bytes of data may be fetched from the instruction cache 125 in one cycle, and up to four bytes may be written to the instruction buffer 124.

The byte aligner circuit 122 aligns the data outside of the instruction cache RAM and supplies the aligned data to the instruction buffer 124. As described in more detail below, the preceding two bytes in the instruction buffer 124 are decoded to determine the length of the virtual machine instruction. As described in more detail below, the command buffer 124 detects valid commands in the queue and updates the entries.

The instruction cache controller 121 also provides a data path and provides control for handling instruction cache misses. In the case of an instruction cache miss, the instruction cache controller 121 generates a cache charge request to the I / O bus and memory interface unit 110.

When receiving data from the external memory, the instruction cache controller 121 writes data to the instruction cache 125, which is also bypassed to the instruction buffer 124. As soon as the data is available from external memory and before the cache filling is complete, the data is bypassed into the command buffer 124.

The instruction cache controller 121 continues to patch consecutive data until the instruction buffer 124 is full or a branch or trap occurs. In one embodiment, command buffer 124 is considered full if there are more than 8 bytes of valid entries in buffer 124. Thus, in general, eight bytes of data are written from the external memory to the instruction cache 125 in response to a cache charge request sent by the instruction cache unit 120 to the interface unit 110. If a branch or trap occurs while processing an instruction cache miss, the trap or branch is executed only after the miss processing is complete.

If an error occurs during an instruction cache filling transaction, an error indication is generated and stored in the instruction buffer 124 according to the virtual machine instruction, ie the error bit is set. The line is not written to the instruction cache 125. Thus, a bad cache fill transaction behaves as if it is not cacheable except that an error bit is set. If the instruction is decoded, a trap is generated.

The instruction cache controller 121 also services non-cacheable instruction reads. The instruction cache enable (ICE) bit of the processor status register in register set 144 is used to define whether the load can be cached. If the ICE bit is cleared, the instruction cache unit 120 treats all loads as non-cacheable loads. The instruction cache controller 121 issues a noncacheable request to the interface unit 110 for a noncacheable instruction. If data is valid on the cache charge bus for non-cacheable instructions, the data is bypassed into the instruction buffer 124 and not written to the instruction cache 125.

In this embodiment, the instruction cache 125 is an 8 byte line size cache that is mapped directly. The instruction cache 125 has one cycle latency. The cache size is configurable into 0K, 1K, 2K, 4K, 8K, and 16K bytes when K stands for kilo. The default size is 4K bytes. Each line has a cache tag entry associated with the line. Each cache tag contains a 20-bit address tag field and one valid bit for the default 4K byte size.

In one embodiment, the instruction buffer 124, which is a 12-byte deep FIFO (first-in, first-out) buffer, disconnects the patch step 301 (FIG. 3) from the rest of the pipeline 300 for performance reasons. Each instruction in buffer 124 (FIG. 1) has an associated valid bit and an error bit. If the valid bit is set, the instruction associated with that valid bit is a valid instruction. If an error bit is set, the patch of the instruction associated with that error bit is an invalid transaction. The command buffer 124 generates a signal for passing data to and from the command buffer 124, and stores a valid entry in the command buffer 124, i.e., an entry having a set of valid bits. Not shown).

In one embodiment, four bytes may be received into the command buffer 124 in a given cycle. Up to five bytes, indicating up to two virtual machine instructions can be read into the instruction buffer 124 in a given cycle. Alternative embodiments that provide for folding of multi-byte virtual machine instructions and / or for providing folding of two or more virtual machine instructions provide higher input / output bandwidth. Those skilled in the art will recognize many suitable instruction buffer designs, including alignment logic, circular buffer designs, and the like. If a branch or trap occurs, all entries in the command buffer 124 are empty and the branch / trap data moves to the top of the command buffer 124.

An execution unit 140 is shown integrated in the embodiment of FIG. 1. However, in another embodiment, the instruction decode unit 130, integer unit 142 and stack management unit 150 are considered single precision integer execution units, and floating point execution unit 143 is a separate optional unit. do. In other embodiments, various elements in an execution unit may be implemented using the execution unit of another processor. In general, the various elements included in the various units of FIG. 1 are illustrative only in one embodiment. Each unit may be implemented in all or part of the elements shown. Again, decisions are made based on cost-performance trade-offs.

Instruction Decode Unit

As mentioned above, the virtual machine instructions are decoded in the decode stage 302 (FIG. 3) of the pipeline 300. In an embodiment, two bytes, corresponding to two virtual machine instructions, are fetched from the instruction buffer 124 (FIG. 1). Two bytes are decoded in parallel so that the two bytes correspond to two stack entry instructions of the first load top and the second add-top of the stack instruction, which can be folded into two virtual machine instructions, for example a single equivalent operation. Decide Folding relates to the supply of a single equivalent operation corresponding to two or more virtual machine instructions.

In an embodiment of the hardware processor 100, the single-byte first instruction is folded with the second instruction. However, other embodiments provide for folding of two or more virtual machine instructions, for example two to four virtual machine instructions and multi-byte virtual machine instructions, despite the cost of instruction decoder complexity and increased instruction bandwidth. do. The title of the invention is "INSTRUCTION FOLDING FOR A STACK-BASED MACHINE", the inventors Mark Tremblay and James Michael O'Corner and the like are assigned to the assignee of the present application and filed as the same as the present application and are hereby incorporated by reference. See US patent application Ser. No. 08 / 786,351. Embodiments In the embodiment of processor 100, if the first byte corresponding to the first virtual machine instruction is a multi-byte instruction, the first and second instructions are not folded.

The optional current object loader folder 132 is named “INSTRUCTION FOLDING FOR A STACK-BASED MACHINE” and the inventors such as Mark Tremblay and James Michael O'Connor are assigned to the assignee of the present application. , An instruction folding as described in more detail in US patent application Ser. No. 08 / 786,351, incorporated herein by reference, the simulation results of which appear to be particularly frequent, making virtual machine instructions the preferred target for optimization. Use a sequence. In particular, this method call typically loads the object reference of the corresponding object into the operand stack and fetches the fields from the object.

Quick mutations are not part of the virtual machine instruction set (see Appendix I in Chapter 3) and are not visible outside the Java virtual machine implementation. However, within virtual machine implementations, quick mutations have proven to be effective optimizations. (See Appendix A of Appendix I; these are part of this specification.) Maintaining records in order to update various instructions for quick transitions in the non-quick to quick translator cache 131 is normal for Quick virtual machine instructions. Changing the virtual machine instructions takes the big advantage that comes from quick mutations. In particular, the invention is named "NON-QUICK INSTRUCTION ACCELERATOR AND METHOD OF IMPLEMENTING SAME", Mark Tremblay and James Michael O'Corner and others are inventors, assigned to the assignee of the present application and filed on the same day as the present application, As described in more detail in US patent application Ser. No. 08 / 788,805, which is hereby incorporated by reference, when information required for initiating execution of instructions is first gathered, the information is stored in the non-quick to quick translator cache 131. As a tag, it is stored in the cache according to the value of the program counter PC and the instruction is recognized as a quick-variant. In one embodiment, this is executed with self-modifying code.

When there is a subsequent call of such an instruction, the instruction decode unit 130 simply retrieves the instruction as recognized as a quick-variance and the information needed to initiate execution of the instruction from the non-quick-to-quick translator cache 131. Detect if The non-quick to quick translator cache is an optional part of the hardware processor 100.

In terms of branching, very short pipes with quick branch resolution are sufficient for most implementations. However, for example, a suitable simple branch prediction mechanism such as branch predictor circuit 133 may be introduced. Execution for the branch predictor circuit 133 includes branches based on opcodes, branches based on offsets, or branches due to a two-bit counter mechanism.

JAVA virtual machine specification defines a command to invoke the virtual keuneon (invokenonvirtual), and the operation code 183 calls the maeseodeu when executed. The opcode is followed by index byte 1 and index byte 2 (see Appendix I). Operand stack 423 contains a reference to the object and some arguments when this instruction is executed.

Index bytes 1 and 2 create an index into the constant pool of the current class. The item in the constant pool at that index points to the complete method symbol and class. The symbols are defined in Appendix I, the description of which is introduced here by reference.

The short, unusual identifier, the method symbol for each method, is enhanced within the method table of the indicated class. The result of the lookup is a block of methods indicating the type of the method and the number of arguments for the method. Object references and arguments pop the stack of this method and are the initial values of the new method's local variables. Execution then resumes with the first instruction of the new method. When executed, the instruction invokevirtual , operator 182 and invokestatic , operator 184 invoke the same processing as just described. In each case, pointers are used to enhance method blocks.

The method argument cache 134, which is also an optional feature of the hardware processor 100, is used in the first embodiment to follow the pointer to the method block as a tag, the method's method for use after the first call to the method. Save the block. The instruction decode unit 130 creates a pointer using index bytes 1 and 2 and then uses the pointer to retrieve a method block for that pointer in the cache 134. This makes it faster to build a stack frame for a newly invoked method in the background of subsequent method calls. Another embodiment may use a program counter or method recognizer as a reference to the cache 134. If there is a cache miss, the instruction is executed in the normal fashion and thus cache 134 is updated. The particular process used to determine which cache entry has been rewritten is not a feature aspect of the present invention. For example, at least recently used criteria may be implemented.

In another embodiment, the method argument cache 134 is used to store a pointer to a method block for use in accordance with the method's program counter PC value as a tag after the first call to the method. The instruction decode unit 130 accesses the cache 134 using the program counter PC value. If the program counter PC value is equal to one tag in the cache 134, the cache 134 supplies the instruction decode unit 130 with the tag stored with the pointer. The instruction decode unit 130 retrieves the method block for the method using the supplied pointer. Considering these two embodiments, other embodiments will be apparent to those skilled in the art.

Wide index progressor 136, which is an optional element of hardware processor 100, is a particular embodiment of instruction folding for instruction wide . Wide index progressor 136 treats the opcode encoding as an extension of the index operand for the immediately following virtual machine instruction. In this manner, the wide index advancer 136 is responsible for storing the local variable storage 421 when the instruction decode unit 130 exceeds the single byte index and addressable number without causing a separate execution cycle for the instruction wide . To provide indexes.

Aspects of instruction decoder 135, in particular instruction folding, non-quick to quick translator cache 131, current object loader folder 132, branch predictor 133, method argument cache 134, and wide index progression 136 is also useful in execution using a software interpreter or timely compiler, since these elements can be used to accelerate the operation of the software interpreter or timely compiler. In the above execution, the virtual machine instructions are typically translated into instructions for a processor that executes an interpreter or compiler using, for example, a Sun processor, a DEC processor, an Intel processor, or a Motorola processor, for example an element Their operation is modified to keep the processor running. Conversion from virtual machine instructions to other processor instructions is possible by translators in ROM or by simple software translators.

Integer Execution Unit

The integer execution unit (IEU) includes an instruction decode unit 130, an integer unit 142, and a stack management unit 150, and is responsible for the execution of all virtual machine instructions except floating point related instructions. Floating point related instructions are executed in the floating point unit 143.

The integer execution unit (IEU) interacts with the instruction cache unit 120 at the front end to patch the instruction, interacts with the floating point unit (FPU) 143 to execute the floating point instruction, and finally the data cache unit Interact with (DCU) 160 to load and store relevant instructions. The integer execution unit (IEU) also includes a microcode ROM 141 that contains instructions for executing specific virtual machine instructions related to integer operations.

The integer execution unit (IEU) includes a cached portion of the stack 400, ie stack cache 155. Stack cache 155 provides fast storage for local variable entries associated with the current method, such as operand stack and operand stack 423 and local variable storage 421 entries. Nevertheless, the stack cache 155 is associated with the current method, depending on the number of local variable entries and operand stacks that are less than all or all local variable entries or all operand stack entries and local variable entries that may appear in the stack cache 155. It can provide enough storage for local variable entries and all operand stacks. Likewise, local entries and / or operand stacks for invoking additional entries, such as methods, may appear in stack cache 155 if space permits.

Stack cache 155 is a 64-entry 32-bit wide array that is physically executed as a register file in one embodiment. The stack cache 155 has three read ports, two of which are assigned to the integer execution unit (IEU) and one to the dribble management unit 151. The stack cache 155 also has two write ports, one of which is designated to the integer execution unit (IEU) and the other to the dribble management unit 151.

The integer unit 142 maintains variables, such as local variables, and various pointers used to access operand stack values within the stack cache 155. The integer unit 142 also maintains a pointer for detecting whether a stack cache hit has occurred. Runtime exceptions are caught and handled by an exception handler executed using information in microcode ROM 141 and circuit 170.

Integer unit 142 includes a 32-bit ALU to support computational operations. Operations supported by the ALU include addition, subtraction, shift, exclusive OR, comparison, over, under, and bypass. ALU is also used to determine the address of a conditional branch while a separate comparator determines the appearance of a branch instruction.

The most common set of instructions that runs cleanly through the pipeline is a group of ALU instructions. The ALU instruction reads the operand from the top of stack 400 in decode step 302 and uses the ALU in execution step 303 to compute the result. The result is written back to the stack 400 in the write-back step 305. There are two levels of bypass that are needed if subsequent ALU operations are accessing the stack cache 155.

Since the stack cache port is 32-bit wide in this embodiment, the double precision and long data operations have two cycles. Shifters also appear as part of the ALU. If the operand is not available to the instruction of the decode stage 302 or is at the beginning of the execute stage 303, the interlock holds the pipeline stage before the execute stage 303.

The instruction cache unit interface of the integer execution unit IEU is a validity / acceptance interface in which the instruction cache unit 120 carries instructions to the instruction decode unit 130 in a fixed field along the valid bits. The command decoder 135 responds by signaling how many byte aligner circuits 122 need to shift, or how many byte command decode units 130 can consume in the decode step 302. The instruction cache unit interface also informs the instruction cache unit 120 for branch mis-prediction conditions and informs the branch address in the execution step 303. The trap, when taken, is also similarly assigned to the instruction cache unit 120. The instruction cache unit 120 can hold the integer unit 142 by not participating in any valid bits in the instruction decode unit 130. The instruction decode unit 130 can hold the instruction cache unit 12 by not engaging the shift signal in the byte aligner circuit 122.

The data cache interface of the integer execution unit IEU is a validity-receiving interface, where the integer unit 142 performs a load or store operation according to its characteristics, eg, non-cache, special storage, etc., in the execution step 303. Signal to data cache controller 161 in 160. The data cache unit 160 may return data to the load and control the integer unit 142 using the data control unit hold signal. If it is a data cache hit, the data cache unit 160 returns the requested data and then releases the pipeline.

In the case of a storage operation, the integer unit 142 also supplies data according to the address of the execution step 303. The data cache unit 160 may hold the pipeline of the cache step 304 if the data cache unit 160 is in use, such as line charging or the like.

Floating point operations are specifically handled by the integer execution unit IEU. The instruction decoder 135 patches and decodes the floating point unit 143 related instructions. The instruction decoder 135 sends a floating point operation operand for execution to the floating point unit 142 of the decode step 302. While floating point unit 143 busy while performing floating point operation, integer unit 142 stops the pipeline and waits until floating point unit 143 signals integer unit 142 that the result is useful. do.

The floating point ready signal from the floating point unit 143 indicates that the execution step 303 of the floating point operation has ended. In response to the floating point ready signal, the result is written back into stack cache 155 by integer unit 142. Floating point load and store are handled entirely by the integer execution unit IEU, because operands for both the floating point unit 143 and the integer unit 142 are found in the stack cache 155.

Stack Management Unit

The stack management unit 150 stores the information and provides the operands to the execution unit 140. Stack management unit 150 also manages overflow and underflow of stack cache 155.

In one embodiment, the stack management unit 150 is configured to retrieve the operands of the stack cache 155, the execution unit 140, which are three read ports, two write port register files in one embodiment, as described above. A stack control unit 152 for the two read ports and one write port used and for providing control signals for storing data from the write-back register or data cache 156 to the stack cache 155, And a dribble manager 151 that speculatively dribble data in and out of the stack cache 155 into memory whenever overflow or underflow is in the stack cache 155. In the embodiment shown in FIG. 1, the memory includes a data cache 165 and any memory storage area interfaced by the memory interface unit 110. In general, the memory includes a suitable memory hierarchy including cache, addressable read / write memory storage, secondary storage, and the like. The dribble manager 151 also provides the necessary control signals for one write port and one read port of the stack cache 155 used only for background dribbling.

In one embodiment, the stack cache 155 serves as a circular buffer that ensures that the stack grows or shrinks in a predictable manner to avoid overflows or overwrites. The storage and restore of values from and into the data cache 165 is controlled by the dribble manager 151 using, in one embodiment, a high / low water mark.

The stack management unit 150 provides an execution unit 140 with two 32-bit operands in a given cycle. Stack management unit 150 may store a single 32-bit result in a given cycle.

The dribble manager 151 handles filling and spilling of the stack cache 155 by speculatively dribbling data in and out of the data cache 165 and into and out of the stack cache 155. The dribble manager 151 generates a pipeline delay signal for delaying the pipeline when a stack overflow or underflow condition is detected. The dribble manager 151 also keeps track of the requests sent to the data cache unit 160. The single request to the data cache unit 160 is a 32-bit continuous load or store request.

The hardware structure of the stack cache 155, except for long operands (double integer and double floating point numbers), does not imply an inherent operand patch for the opcode adds a delay to the opcode execution. The number of entries in operand stack 423 (FIG. 4A) and the local variable storage 421 maintained in stack cache 155 represent hardware / performance tradeoffs. At least some operand stack 423 and local variable storage 421 entries are needed to achieve good performance. In the embodiment shown in FIG. 1, at least the top three entries of the operand stack 423 and the first four local variable storage 421 entries are preferably represented in the stack cache 155.

One major function provided by stack cache 155 (FIG. 1) is to emulate a register file that is always accessible to the top two registers without extra cycles. A small hardware stack is sufficient if adequate information is provided to load / store the value to / from memory in the background, thus preparing a stack cache 155 for incoming virtual machine instructions.

As described above, all items on the stack 400 are placed in 32-bit words (regardless of size). This tends to waste space when many small data items are used, but this is relatively simple and frees from muxing or tagging. Thus, an entry in stack 400 represents a value and not a number of bytes. Double and double floating point numbers require two entries. To reduce the number of read and write ports, two cycles are required to read two double integers or two double floating point numbers.

The mechanism for spilling and filling the operand stack from the stack cache 155 to memory by the dribble manager 151 may take one of several other types. At any time one register may be charged or spilled, or several blocks of registers may be charged or spilled at one time. Simple scoreboard methods are appropriate for stack management. In its simplest type, a single bit indicates whether a register in stack cache 155 is currently valid. In addition, some embodiments of stack cache 155 use a single bit to indicate whether the data content of a register is stored on stack 400, ie, the register is dirty. In one embodiment, the high and low check heuristics determine when an entry is stored in the stack 400 and restored from the stack 400 (FIG. 4A). Alternatively, when the top of the stack approaches the bottom of the stack cache 155 by a fixed or otherwise programmable number of entries, the hardware starts loading the registers from the stack 400 into the stack cache 155. Another embodiment of the stack management unit 150 and the dribble management unit 151 is the title "METHOD FRAME STORAGE USING MULTIPLE MEMORY CIRCUITS" by Mark Tremblay and James Michael O'Connor, and assigned to the assignee of the present application, See US patent application Ser. No. 08 / 787,736, which is incorporated herein by reference, and the title "STACK CACHING, assigned to the assignee of the present application, hereby incorporated by reference, which is incorporated herein by reference; See also US Patent Application No. 08 / 787,617 entitled USING MULTIPLE MEMORY CIRCUITS.

In one embodiment, stack management unit 150 also includes an optional local variable look-side cache 153. The cache 153 is most important in applications where neither the local variables of the method and the operand stack 423 are located on the stack cache 155. If the cache 153 is not contained within the hardware processor 100, there is a miss in the stack cache 155 when the local variable is accessed, and the execution unit 140 accesses the data cache unit 160, which is This slows down execution. In contrast, with cache 153, local variables are retrieved from cache 153 and there is no delay in execution.

One embodiment of a local variable look-side cache 153 is shown for methods 0 through 2 on stack 400 in FIG. 4D. At local variable zero for method 0, M (where M is an integer) is stored in plane 421A_0 of cache 153 and plane 421A_0 is accessed when method number 402 is zero. At local variable zero for method 1, N (where N is an integer) is stored in plane 421A_1 of cache 153 and plane 421A_1 is accessed when method number 402 is one. P at local variable zero for method 1, where P is an integer, is stored in plane 421A_2 of cache 153 and plane 421A_2 is accessed when method number 402 is two. It should be noted that the various planes of cache 153 may vary in size, but typically the plane of each cache has a fixed size determined experimentally.

When a new method is called, for example when method 2 is called, a new plane 421A_2 in cache 153 is loaded into a local variable for that method, and in one embodiment the method number register 402 is a counter. Is changed (eg, incremented) to indicate the plane of cache 153 containing the local variables of the new method. It should be noted that local variables are sorted within cache 153 so that cache 153 is effectively a direct mapping cache. Thus, when a local variable is needed for the current method, the variable is accessed directly from the most recent plane in the cache 153, that is, the plane recognized by the method number 402. When the current method returns, for example, to method 2, the method number register 402 changes, for example, decrements to indicate the previous plane 421A_1 of the cache 153. The cache 153 is made as wide and deep as needed.

Data Cache Unit

The data cache unit 160 (DCU) manages all requests for data in the data cache 165. The data cache request comes from the dribbling manager 151 or the execution unit 140. The data cache controller 161 coordinates these requests while giving priority to execution unit requests. In response to the request, the data cache controller 161 generates addresses, data and control signals for the tag RAM and data in the data cache 165. For data cache hits, data cache controller 161 reorders the data RAM output to provide correct data.

The data cache controller 161 also generates a request to the I / O bus and memory interface unit 110 for data cache misses and for non-cacheable load and store. The data cache controller 161 provides control logic and data paths for handling non-cacheable requests, and provides data path control functions and data paths for handling cache misses.

For a data cache hit, data cache unit 160 returns data to execution unit 140 in one cycle for loading. Data cache unit 160 also takes one cycle for write hits. In the case of a cache miss, the data cache unit 160 delays the pipeline until the requested data is available from external memory. For both non-cacheable load and store, data cache 165 is bypassed and requests are sent to the I / O bus and memory interface unit 161. Non-aligned loads and stores to data cache 165 are trapped in software.

Data cache 165 is an interactive set associative, write back, write allocation and 16-byte line cache. Cache size is configurable in 0, 1, 2, 4, 8 and 16 kilobyte sizes. The initial size is 8 kilobytes. Each line has a cache storage entry associated with each line. When cache misses, 16 bytes of data are written to cache 165 from external memory.

Each data cache tag includes a 20-bit address tag field, one valid bit, and one dirty bit. Each cache tag is also associated with the most recently used bit used for the replacement policy. In order to maintain multiple cache sizes, the width of the tag field can also be changed. If the cache enable bit in the processor service register is not set, the load and store are treated as non-cacheable instructions by the data cache controller 161.

A single 16-byte write back buffer is provided to write back dirty cache lines that need to be replaced. The data cache unit 161 provides up to 4 bytes for reading and up to 4 bytes of data can be written to the cache 165 in a single cycle. Diagnostic reads and writes can be performed in the cache.

Memory Allocation Accelerator

In one embodiment, data cache unit 160 includes a memory allocation accelerator 166. Typically, when a new object is created, the field of the object is fetched from external memory, stored in the data cache 165, and the field is cleared to zero. This is a time consuming process and is eliminated by the memory allocation accelerator 166. When a new object is created, no fields are retrieved from external memory. Rather, memory allocation accelerator 166 simply stores zero lines in data cache 165 and marks the lines of data cache 165 as dirty. Memory allocation accelerator 166 is particularly advantageous for write-back caches. Since memory allocation accelerator 166 eliminates external memory access, the performance of hardware processor 100 is improved.

Floating Point Unit

Floating-point unit (FPU) 141 includes a microcode sequencer, an input / output section with input / output registers, a floating-point adder or ALU, and a floating-point multiply / divide unit. The microcode sequencer controls the microcode flow and microcode branching. The input / output section provides control for input / output data transfer, and input data loading and output data unloading registers. These registers also provide intermediate result storage.

Floating-point adder-ALU includes combinatorial logic used to perform floating-point addition, floating-point subtraction, and switching operations. The floating point multiplication / division unit includes hardware for performing multiplication / division and remainder.

Floating-point unit 143 consists of a microcode engine with a 32-bit data path. This data path is often reused many times during the calculation of the result. Double precision operations require two to four times the number of cycles of a single precision operation. The floating point ready signal asserts one cycle before completion of a given floating point operation. This causes the integer unit 142 to read the floating point unit output register without any wasted interface cycles. Thus, the output data is possible to read one cycle after the floating point ready signal is asserted.

Execution Unit Accelerator

Because the JAVA virtual machine specification in Appendix I is hardware independent, virtual machine instructions are not optimized for certain general types of processors, for example, complex instruction set computer (CISC) processors, or reduced instruction set computer (RISC) processors. Do not. In fact, some virtual machine instructions have CISC characteristics and others have RISC characteristics. This dual characteristic complicates the operation and optimization of the hardware processor 100.

For example, the JAVA virtual machine specification defines an operation code 171 for a command lookupswitch, which is a conventional switch statement. The data string to the instruction cache unit 120 includes an operation code 171, N-way switch statement recognition followed by three bytes of padding at zero. The number of padding bytes is chosen such that the first operand byte starts at an address that is a multiple of four. Here, data streams are generally used to represent information provided to a particular element, block, component or unit.

Following the padding byte in the data stream is a series of signed 4-byte pairs. The first pair is special. The first operand in the first pair is the default offset for the switch statement that is used when the argument of the switch statement, called an integer key or the current match value, is not equal to any of the match values in the switch statement. The second operand of the first pair defines several pairs that follow in the data stream.

Each subsequent operand pair in the data stream has a first operand that is a match value and a second operand that is an offset. If the integer key is equal to either of the match values, the offset in the pair is added to the address of the switch statement to define the address at which execution branches. Conversely, if the integer key is not equal to any of the match values, the default offset in the first pair is added to the address of the switch statement to define the address at which execution branches. Direct execution of this virtual machine instruction takes many cycles.

To improve the performance of the hardware processor 100, the lookup switch accelerator 145 is included in the hardware processor 100. Lookupswitch accelerator 145 includes an associated memory that stores information related to one or more lookupswitch statements. For each lookup switch statement, ie for each command lookup switch , this information includes a lookup switch identifier value, ie, a program counter value, a plurality of match values, and a corresponding plurality of jump offset values associated with the lookup switch statement.

The lookupswitch accelerator 145 determines whether the current instruction received by the hardware processor 100 corresponds to a lookupswitch statement stored in the associated memory. The lookup switch accelerator 145 also determines whether the current match value associated with the current command corresponds to one of the match values stored in the associated memory. The lookupswitch accelerator 145 accesses a jump offset value from the associated memory when the current command corresponds to a lookupswitch statement stored in memory and the current match value corresponds to one of the match values stored in the memory. The jump offset value corresponds to the current match value.

A look-up switch accelerator 145 also has an associated memory comprising a circuit for searching the current lookup switch jump offset value and a match associated myeongryeongmunwa when not already included in the jump offset values associated with a match with the current lookup switch statement. The look-up switch accelerator 145 is named "LOOK-UP SWITCH ACCELERATOR AND METHOD OF OPERATING SAME", and Mark Tremblay and James Michael O'Corner and the like are assigned to the assignee of the present application and are referred to herein. It is described in detail in US patent application Ser. No. 08 / 788,811, which is incorporated by reference.

In the process of initiating the execution of the method of the object, the execution unit 140 accesses the method vector and searches for one or one indirection level of the method pointer in the method vector. Execution unit 140 uses the accessed method pointer to access the corresponding method, that is, the second level of indirection.

In order to reduce the level of indirection in the execution unit 140, a dedicated copy of each method is accessed for each object by the object. Execution unit 140 then accesses the method using a single level of indirection. That is, each method is accessed directly by a pointer from the object. This eliminates the level of indirection previously introduced by the method pointer. By reducing the level of indirection, the operation of the execution unit 140 can be accelerated. By reducing the level of indirection, the operation of the execution unit 140 can be accelerated. Accelerating the execution unit 140 by reducing the level of indirection is the name of the invention "REPLICATING CODE TO ELIMINATE A LEVEL OF INDIRECTION DURING EXECUTION", the inventors of Mark Tremblay and James Michael O'Corner and the like, Assigned to the assignee of U.S. Patent No. 08 / 787,846, which is incorporated herein by reference.

getfield-putfield accelerator

Various transform lookaside buffer (TLB) types of other specific functional units and structures are optionally included in the hardware processor 100 to accelerate access to the constant pool. For example, the JAVA virtual machine specification may include a command putfield that sets a field in an object when executed, a getfield that obtains a field from an object when executed with an operation code 181, and an operation code 180. Decide In these instructions, the operation code is followed by index byte 1 and index byte 2. The operand stack 423 includes only a reference to an object for the reference and the Get command field for the object followed by a value for the foot command field.

Index bytes 1 and 2 are used to create an index into the constant pool of the current class. The items in the constant pool at that index are field references to class names and field names. The item is decomposed into a field block pointer having both the intrabyte byte width and the intrabyte byte offset.

Selective nuggets field in the execution unit 140-foot field accelerator 146 is cached in instruction nuggets field or command stores the field block pointer for the foot field and recognize an item in the constant pool, even if they are decomposed into the field block pointer as a tag Used after the first invocation of the command, depending on the index used to do so. Subsequently, execution unit 140 creates an index using index bytes 1 and 2 and supplies the index to getfield-footfield accelerator 146. If the index matches any of the indexes stored as a tag, that is, a hit, the field block pointer associated with that tag is retrieved and used by execution unit 140. Conversely, if no match is found, execution unit 140 performs the operation described above. Getfield-footfield accelerator 146 is implemented without the self modifying code used in the quick command conversion embodiment described above.

In one embodiment, getfield-footfield accelerator 146 includes an associated memory having a first portion holding indices serving as tags and a second portion holding a field block pointer. When an index is supplied through the input to the first portion of the associated memory, and if there is a match with one of the stored indices, the field block pointer associated with the stored index matched with the input index is the output from the second portion of the associated memory.

Bounds Check Unit

Bound inspection unit 147 (FIG. 1) in execution unit 140 is an optional hardware circuit that checks each access to elements of the array to determine if the access is to a location within the array. When the access is to a location outside of the array, bound check unit 147 issues an active array bound exception signal to execution unit 140. In response to the active array bound exception signal, execution unit 140 begins execution of an exception handler stored in microcode ROM 141 that handles out of bound array access.

In one embodiment, bound check unit 147 includes therein an array identifier for an array (e.g., a program counter value) and associated memory elements having stored therein minimum and maximum values for the array. When an array is accessed, that is, when an array identifier for that array is applied to the associated memory element, and the array appears within the associated memory element, the stored minimum value is the first input signal for the first comparator element and the maximum stored The value is the first input signal for the second comparator element, and the comparator element is sometimes called the comparator element. The second input signal for the first and second comparator elements is a value related to the access of the array element.

No comparator element generates an output signal when the value associated with access of the array element is less than or equal to the stored maximum and greater than or equal to the stored minimum. However, if either of these conditions is false, a suitable comparator element generates an active array bound exception signal. The more detailed description of the bound inspection unit 147 is named "PROCESS WITH ACCELERATED ARRAY ACCESS BOUND CHECKING", and Mark Tremblay and James Michael O'Corner are the inventors, and are assigned to the assignee of the present application, It is filed on the same day as the application, which is described in detail in US patent application Ser. No. 08 / 786,352, which is hereby incorporated by reference.

The JAVA virtual machine specification specifies that certain commands can cause certain exceptions. Checks of these exception conditions are implemented and hardware / software mechanisms for dealing with them are provided to the hardware processor 100 by information in the microcode ROM 141 and the program counter and trap control logic 170. Others include pushing a trap type on the stack with a trap vector style or a single trap target, such that the provided trap handler routine determines the appropriate behavior.

No external cache is needed for the architecture of the hardware processor 100. No translation lookaside buffer needs to be maintained.

5 shows some possible additional elements for the hardware processor 100 to create a unique system. Circuitry to maintain the eight functions shown, i.e. NTSC encoder 501, MPEG 502, Ethernet controller 503, VIS 504, which can be integrated into the same chip as the hardware processor 100 of the present invention, ISDN 505, I / O controller 506. ATM assembly / reassembly 507 and wireless link 508 are shown.

6A is a block diagram of a dual instruction set processor 690 implemented on a single silicon chip as one embodiment of the invention. The dual instruction set processor 690 also has the ability to decode and execute virtual machine instructions, i.e., the first instruction set received from a network or the like, and to decode and execute a second instruction set provided from local memory or a network or the like.

The first and second instruction sets are for different computer processor architectures. In one embodiment, the first set of instructions is a virtual machine instruction, such as a JAVA virtual machine instruction, and the second set of instructions is a native instruction for a conventional microprocessor architecture, such as the architecture described above.

Initially, when dual instruction set processor 690 boots up, an operating system running on dual instruction set processor 690 typically causes the processor to execute instructions in the native instruction set. When an application that uses or requires instructions in the virtual machine instruction set is loaded, the operating system causes the datastream to proceed to a translation unit 691.

In one embodiment, translation unit 691 is a ROM that includes an interpreter from virtual machine instructions to native instructions. This ROM may also contain microcode that is used to implement some virtual machine instructions on the processor 690. Optionally, a software implementation of the interpreter may be realized by processor 690 to convert virtual machine instructions in the datastream into native instructions.

Primitive instructions from translation unit 691 are decoded by decode unit 692, which is used in a conventional microprocessor architecture. The decoded instructions are then executed by execution unit 693, which is a conventional execution unit for use with a conventional microprocessor architecture. If a microcode routine is included in the translation unit 691 to implement any virtual machine instruction, the microcode routine passes directly to the execution unit 693 for execution.

To those skilled in the art, it is apparent that the processor 690 includes other functional units, memory configurations, and the like, although not shown in FIG. 6A so as not to detract from the features of the present invention. In addition, using certain conventional microprocessor architectures, additional microcode may be required to support the virtual machine environment of interest. Of course, to improve the performance of a conventional microprocessor architecture, the various cache and acceleration units described above may be integrated within the conventional microprocessor architecture.

Dual instruction set processor 690 executes the translated virtual machine instructions directly, eliminating the need for a software interpreter or a timely compiler. Since the translated virtual machine instructions are executed immediately, performance is superior to software interpreters or timely compilers.

In one embodiment of dual instruction set processor 690, the bits in the processor status register are defined as mode select bits. When the mode select bit is in the first state, the signal MODE (FIG. 6A) is active and the datastream 695 is passed to the decode unit 692 through the demultiplexer 696. When the mode select bit is in the second state, the signal MODE is inactive and the data stream 695 is passed through the demultiplexer 696 to the translation unit 691 and the translated command stream from the translation unit 691 is It is input to the decode unit 692. Thus, in this embodiment, the virtual machine is implemented within a conventional microprocessor architecture.

In another embodiment described in FIG. 6B, dual instruction set processor 600, sometimes referred to as processor 600, includes: stack 655, which may be stack 400 (FIG. 4A); A first command decoder 635 for receiving a command stream from a network or local memory; A second command decoder 660 for receiving a selected command from a network or local memory; An instruction execution unit 650 including a first execution unit 640; And stack 655, which may be stack 400 (FIG. 4A), that is, used by first execution unit 640. It will be apparent to one of ordinary skill in the art that the processor 600 includes other functional units. However, other functional units are not of interest to the present invention and are not described in order not to obscure the detailed description of the present invention. In addition, the second execution unit 622 may include a microcode routine to support the environment required by the first execution unit 640.

Although several functional units are shown on one die in this embodiment, this is for illustrative purposes only and the present invention is not limited to this particular embodiment. In the present disclosure, one of ordinary skill in the art will be able to implement the principles of the present invention in a separate processor, integrated processor, or any other desired physical structure.

The second instruction decoder 660 can be of any type well known in the art, including but not limited to a decoder for decoding another set of stack instructions. In one embodiment of the invention, the second command decoder 660 is a RISC type command decoder. In this embodiment, the second execution unit 662 is connected to a flat register as opposed to the stack architecture of the first execution unit 640 in the instruction execution unit 650 as a RISC type instruction execution unit. have. In another embodiment of the present invention, the second command decoder 660 is a CISC type command decoder and the second execution unit 662 is a CISC type execution unit. In yet another embodiment, the second instruction decoder 660 is a VLIW type instruction decoder and the second execution unit 662 is a VLIW type execution unit.

As will be described in detail below, in one embodiment of the present invention, the first instruction decoder 635 is identical to the instruction decoder 135 in the instruction decode unit 130 (FIG. 1). The second command decoder 660 (FIG. 6B) is active in response to the execution of the set mode command in the stream of virtual mode commands, and the command stream toggles from the first command decoder unit 635 to the second command decoder 660. do. Once the second command decoder 660 is active, the instructions decoded from the second command decoder 660 are supplied to the second execution unit 662 in the instruction execution unit 650.

This configuration has several advantages. As shown in Appendix I, the JAVA virtual machine specification leaves some opcodes for further extensions, i.e. the specs do not define all possible opcodes 256. However, even these other extensions are not enough to provide all the commands you want. With processor 600, raw instructions for execution unit 662 can be used to implement the instructions in the JAVA virtual machine specification. For example, if an application requires an ideological function, such as a sine or cosine function, this ideological function replaces the set mode command and the commands used in the native instruction set of execution unit 662 to execute the desired function. Can be implemented.

Therefore, in accordance with the principles of the present invention, one way to increase the number of virtual machine instructions beyond the 256 limit is to assign a special opcode, such as opcode 255, as a set mode instruction. As described above, execution of the set mode instruction causes the second instruction decoder 660 to operate, and toggles or switches a second instruction set, such as a RISC type of instruction, to the second instruction decoder 660 to specify the JAVA virtual machine specification. Perform unsupported calculations

Execution of the set mode command causes the operating system to change the state of the mode bit, which in turn activates the second command decoder 660 and the second execution unit 662. Once the calculation is complete, the operating system detects the completion and resets its mode bits so that the input datastream can be returned to the first command decoder 635.

Thus, in this embodiment of the present invention where the second instruction execution unit 662 is a RISC type execution unit, a method of activating and executing RISC instructions by the second instruction decoder 660 and the second execution unit 662 is described. It can be seen in FIG. 7. The set mode instruction 701, i.e., operation code 255 (FIG. 7) in the data stream 700, is decoded by the instruction decoder 135 (FIG. 6B) and executed by the first execution unit 640, and the set The state of the mode bit is changed to activate the second command decoder 660 and the second execution unit 662. Immediately following the set mode instruction 701, the instructions in the data stream 700 are RISC instructions, that is, opcodes for RISC execution units and their associated operands.

Next, the instruction decoder 135 or other hardware in the processor 600 routes the information 702 to the second instruction decoder 660 and bypasses the decoding of the instruction decoder 135. For example, the demultiplexer and signal mode of FIG. 6A can be integrated into the processor 600.

6C shows that the first instruction decoder 635, the first execution unit 640, and the stack 655 each have an instruction decoder 135, an execution unit 140, and a stack cache 155 of the hardware processor 100. More details of another embodiment of the present invention are shown. In this embodiment, the first and second execution units are separate and the second execution unit 662 is a RISC execution unit coupled with the flat register 664. In addition, the second execution unit 662 may include microcode executed to support the JAVA virtual machine environment. Therefore, processors 600 and 600A may execute JAVA virtual machine instructions that include opcodes and may also be optimized to execute a second instruction set for other computer processor architectures.

Thus, in accordance with the principles of the present invention, a data stream comprising instructions is provided to the first instruction decoder 636. Upon executing a predefined command in the data stream, the data stream is toggled to an active second command decoder 660 to process the continuous information in the data stream. Therefore, the instruction set has two different types, platform independent instruction set, and platform dependent instruction set, which are decoded and executed by the dual instruction set processor 600 of the present invention. This has the advantage that the operation code space of the second execution unit can be included with the virtual machine operation code space to improve the performance and the capabilities of the virtual machine.

Referring to FIG. 8, shown is a block level diagram of a computer system 800 using a processor 801, which is one of the processors 690, 600, and 600A of the present invention and has a modem 802 and a local memory ( 804. In this embodiment of the invention, the modem 802 communicates with a network such as the Internet or an intranet to receive virtual machine instructions for execution. Optionally, the modem 802 may be replaced with a network card of the computer system 800 for an intranet. Thus, modem 802 represents a communication interface unit that can be connected for communication with a network. As will be apparent to one of ordinary skill in the art, the communication interface unit receives a first set of instructions in a first format and supplies a first set of instructions with the second format as an output signal.

In this embodiment, the processor 801 has two modes of operation. In the first mode of operation, processor 801 receives only virtual machine instructions from the network for execution. In a second mode of operation, immediately after receipt of a predefined instruction within the virtual machine instruction, processor 801 is stored in local memory 804 for execution, RISC, X86, power PC, and / or any other processor architecture. Receive and process other commands for. In this way, instructions not implemented within the virtual machine instructions, such as, for example, instructions for visual arithmetic, such as modeling, dimension drawing, or the like, may be fully implemented using the processor 801. It will be apparent to one of ordinary skill in the art that the processor 801 may receive non-JAVA virtual machine instructions from the network while understanding that the second type of instruction, that is, the application may not require security. will be.

There are many applications in the processors 600 and 600A. For example, computer system 800 is configured to provide a processor 801 with JAVA virtual machine instructions provided from either a public carrier such as the Internet or from local memory 804. A user of the computer system 800 may have a computer program that is written in the JAVA programming language and processed to generate a virtual machine instruction, such as that shown in Figure 2, which is alternately provided from the local memory 804, from a virus or other software problem. You can be certain that it is safe.

For example, a library needed by an application received from the network may be stored in local memory 804. A particular operating system or graphical user interface may include the library as part of the operating system or graphical user interface. Thus, any computer program written in the JAVA programming language can be compiled into two different versions, one of which is not secured for processing by another processor 600 or 600A or another hardware processor 100. It is provided on a network, and another version is used in a local environment, such as local memory 804 or other trusted environment.

The difference between the two compiled versions of the JAVA language source program is that a compiled version that is intended to be executed logically, such as a version stored in local memory 804, is a strong security check such as an array boundary that checks for insecure network versions. There is no need to do it. Therefore, time consuming and unnecessary security checks are not necessary and can be passed. This improves the performance of the processors 600 and 600A in the local environment, but it is also necessary to allow the processor to be used to process virtual machine instructions received on the air carrier.

Earlier, we thought of the network as an insecure environment, and we considered local memory as a trusted environment. However, this is for illustrative purposes only. It will be apparent to those of ordinary skill in the art that transmissions on the Internet, intranets or other networks may be secure and reliable. Thus, in such a situation, the features within the present invention for a trusted environment may be used. Similarly, in some situations the local memory may not be a trusted environment and therefore the principles of the present invention for insecure environments should be used.

Those skilled in the art can add or modify embodiments of the present invention in various ways without departing from the scope and spirit of the various aspects of the present invention with the teachings disclosed herein. In addition, there may be various changes and modifications of the invention which may fall within the spirit and scope of the invention as defined in the appended claims.

(Appendix I)

JAVA virtual machine specification

© 1993, 1994, 1995 Sun Microsystems, Inc.

2550 Garcia Avenue, Mountain View, California

94043-1100 U.S.A.

All rights have been preserved. This BETA feature is publicly available, and its documentation is protected by copyright and distributed under licenses restricting its use, copying, distribution and editing. This disclosure or related document may be reproduced in any type by any means without the authorization of the Sun or its licensors.

Portions of this product may be derived from the UNIX and Barclays 4.3 BSD systems, licensed from the Institute of UNIX Systems and the University of California, respectively. Third-party software from this release is protected by copyright and licensed from good sources.

Restricted Rights Legend: Use, copying or disclosure by the US Government is subject to the restrictions set forth in DFARS 252.227-7013 (c) (1) (ii) and FAR 52.227-19.

Disclosures described in this manual may be protected by one or more US patents, foreign patents, or pending applications.

brand

Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun logo, the Sun Microsystems Computer Corporation logo, WebRunner, JAVA, FirstPerson, and the Firstperson logo and agents are trademarks or registered trademarks of Sun Microsystems Incorporated. The "Duke" character is copyright 1992-1995 Copyright (c) of Sun Microsystems, Inc. All rights have been preserved. Tradenames UNIX is a registered trademark in the United States and other countries, licensed exclusively through X / Open Company, Ltd. OPEN LOOK is a registered trademark of Novell Incorporated. All other product names mentioned herein are their respective trademarks.

All SPARC trademarks, including the SCD Compliant logo, are trademarks or registered trademarks of SPARC International. SPARCstation, SPARCserver, SPARCengine, SPARCworks, and SPARCcompiler are licensed exclusively to Sun Microsystems, Inc. Products bearing the trademark SPARC are based on components developed by Sun Microsystems, Inc.

OPEN LOOK and Sun ^TM Graphical User Interfaces were developed by Sun Microsystems, Inc. for its users and licensees. Sun recognizes Xerox's pioneering efforts in research and development in terms of visual and graphical user harmony for the computer industry. Sun owns a non-exclusive licensor from Xerox to the Xerox Graphical User Interface and also includes a line license under OPEN LOOK GUIs and the line license agreement.

X Window System is a trademark and product of MIT.

This publication is provided “as is” without limitation of any kind, grounds, representations, or implications, of any implied grounds of marketability or reasonableness for a particular purpose or noninfringement. This publication may include technical or recording errors. Changes may be added to the guide periodically: These changes will be combined in new supplements to this publication. Sun Microsystems Inc. may make improvements and / or changes in the products and / or programs described in this publication at appropriate times.

preface

This document describes version 1.0 of the JAVA virtual machine and its educational program. We have written this document to serve as a specification for compiler writers who want to target compiler writers, and as a specification for others who want to implement the following JAVA virtual machine.

A JAVA virtual machine is a virtual machine implemented by emulating software on a real computer. The code for the JAVA virtual machine is stored in a class file, where each class file contains one or more public class code.

Simple and efficient emulation of JAVA virtual machines is possible because the computer's format is compact and efficient bytecode. The implementation of compiled C's native code-rate access is possible to convert bytecode to a computer, although Sun did not make public about its implementation.

The rest of this document is organized as follows.

Chapter 1 describes the structure of the JAVA virtual machine.

Chapter 2 describes the class file format.

Chapter 3 describes bytecodes.

Appendix A contains some configuration by the Sun implementation of the JAVA virtual machine. Portions of the specification are not exact but we describe them here for reference in the implementation. Other implementations of the JAVA virtual machine are available and we may remove Appendix A from future releases.

Sun will authorize JAVA virtual machine trademarks and logos for use in the implementation of this specification. If you are considering implementing a JAVA virtual machine and would like to contact us, please send an e-mail to the address below and we will 100% support for your implementation.

Please send any comments or questions about the implementation of the JAVA Virtual Machine to our email address, JAVA@JAVA.sun.com.

1.JAVA Virtual Machine Architecture

1.1 Supported Data Types

Virtual machine data types include the basic data types of the JAVA language.

byte // 1 byte signed two's complement

short // 2-byte signed two's complement

int // 4 byte signed two's complement

long // 8-byte signed two's complement

float // 4 byte IEEE 754 single precision

double // 8 byte IEEE 754 double precision

char // 2-byte unsigned Unicode character

Approximately all JAVA-type searches are done at compile time. The aforementioned initial type of data need not be represented by the hardware to allow the execution of JAVA. Instead, the bytecode acting as the initial value indicates the operand type of the iadd, ladd, fadd and dadd instructions, for example, the two numbered types are int, long, float and double, respectively.

Virtual machines do not separate instructions for boolean types. Instead, integer instructions, including integer returns, are used to compute boolean values; Byte arrays are used for arrays of booleans.

The virtual machine supports progressive underflow and specifies floating point points in the IEEE 754 format. Older computer systems that do not support the IEEE format will run JAVA fractional programs very slowly.

Other virtual machine data types include the following:

object // 4-byte reference to the JAVA object

returnAddress // 4 bytes used by the jsr / ret / jsr＿w / ret＿w command

Note: The JAVA array was treated as an object.

This specification does not require any particular internal structure for the object. In our implementation, an object reference is treated as a pair of pointers: one for the method table for the object and one for the data allocated for the object. Other implementations can use method table processing rather than inline cache, and this approach is similar to the rapid change in hardware, that is, between the current and 2000 years.

Programs represented by JAVA virtual machine bytecodes are expected to maintain desirable type suppression, and implementations may be denied to execute bicode programs that violate this type suppression.

JAVA virtual machines, on the other hand, are confined by bytecode deionization to run on 32-bit address space computers, which makes it possible to create a version of the JAVA virtual machine that automatically converts bytecodes into 64-bit formats. This transfer technology goes beyond the technical idea of the JAVA virtual machine specification.

1.2 Registers

In some respects, the virtual machine executes a single method of code, and the pc register contains the address of the next bytecode to be executed.

Each method has an allocated memory space to hold the memory.

setting local variables referred to by the vars register;

Operand stack referred to as an optop register; And

Execution environment structure referred to as frame register

Since the local variable size and operand stack are known at compile time, all of this space can be allocated at once, and the size of the execution environment structure is well known to the interpreter.

All of these registers are 32 bits wide.

1.3 Local Variables

Each JAVA method uses a fixed size setting for local variables. They are addressed as word offsets from the vars register. Local variables are all 32 bits wide.

Double precision and double precision are addressed with the index of the first local variable (for example, a local variable with an index includes a double precision that dynamically uses storage at indexes n and n + 1). The virtual machine specification does not require 64-bit values in local variables that are 64-bit aligned. The implementer decides the proper way to split a double integer and a double into two words.

Instructions are provided for loading local variable values on the operand stack to store values from the operand stack into local variables.

1.4 The Operand Stack

Computer instructions take all of the operands from the operand stack, their operation, and returning the result to the stack. We chose a stack organization to easily and easily emulate a computer on a computer with some or irregular registers, such as the Intel 486 microprocessor.

The operand stack is 32 bits wide. It is used not only to receive methods obtained by passing parameters to methods, but also to save operations obtained by supplying variables for operations.

For example, the execution of the command iadd adds two integers together. The two integers are expected to be the two most significant words on the operand stack pushed by the previous instruction. Positive integers are popped from their sums pushed on the stack, added and operand stacks. A co-calculator can be placed on the operand stack and the result of a single operand can be used by the following calculation.

Each initial data type has a specific instruction that knows how to operate on that type of operand. Each operand requires a single location on the stack, more than a double precision operand that requires two locations.

Operands must be computed with operators appropriate to their type. For example, pushing two operands to process them long makes it illegal. This restriction is enforced in the implementation of good by the bytecode verifier. However, a small number of operations (dup ops and swap) operate on the runtime data area as column values of a given width, regardless of type.

In the following description of the virtual machine instructions, the effect of the execution of the instructions on the operand stack is represented as it is with the stack growing from left to right, each represented separately by a 32 bit word. therefore:

stack: ..., value1, value2 ⇒ ..., value3

The operation is started by having value2 on top of the stack with value1 just below the operation. As a result of command execution, value1 and value2 are popped from the stack and replaced with value3 computed by the command. The rest of the stack, omitted, is not affected by the execution of the instruction.

Double and double types take two 32-bit words on the operand:

stack: ..., ⇒ ..., value-word1, value-word2

This specification does not mention how two words were chosen from 64-bit double or double values, and only a specific implementation is needed internally.

1.5 Execution Environment

Information contained within the command environment is used for dynamic linking, normal method return, and fault propagation.

1.5.1 Dynamic Linking

The execution environment includes a reference to the resolver symbol table for the current method and current class that support dynamic linking of the method code. The class files the code for the method for the method being called and can be changed to be accessed by sign. Dynamic linking translates encoding method calls into dynamic method calls, loads the classes needed to interpret undefined codes, and converts variable accesses to the appropriate offsets in the memory structure combined with these variable execution times.

The late combination of this method and the transformation changes to another class that uses the method that breaks this code.

1.5.2 Normal Method Return

If the execution of the current method completes successfully, the value is returned to the calling method. This happens when the calling method executes the appropriate return instruction with the return type.

The execution environment is used when re-memorizing the registers of the pager with the counter program of the pager appropriately incremented to skip method call instructions. Execution then continues to the execution environment of the calling method.

1.5.3 Exceptions and Error Propagation

Anomalies known to JAVA as errors or anomalies in discardable subclasses occur for the following reasons:

Dynamic link failures, such as failing to find the required class files;

Runtime errors such as references through null pointers;

Asynchronous events such as starting with Thread.stop from another thread; And

Program that uses the startup state.

When an abnormality occurs:

The list of catch clauses associated with the current method is examined. Each cache phrase describes the above types to describe and adjust the instruction range for dynamics, and has the address of the code to adjust it.

An abnormality matches a cached phrase if the instruction is within the appropriate instruction range and the abnormal type results in a subtype of zero and type that controls the cached phrase. If a matching cache phrase is found, the system branches to a particular coordinator. If no coordinator is found, the process repeats until all nested cached phrases of the current method have been consumed.

The order of the cache phrase in the list is important. Virtual machine execution continues with the first matching cache phrase. Because the JAVA code is configured, a single list can be retrieved from the linear order to find the ideal (innermost containing applicability) anomaly adjuster for anomalies that generate program counter values for any program counter value. It is possible to sort all the ideal adjusters against. If there is no cache phrase match, the current method has an abnormality that is not caught as a result of it. The execution state of the method is called and this method is re-memorized from the execution environment, and propagation of execution continues through the abnormality generated in this pager.

1.5.4 Additional Information

The execution environment can be extended with additional implementation-specific information such as debugging information.

1.6 Garbage Collected Heap

JAVA heap is a runtime data area from an assigned class example (object). The JAVA language is designed to be valuelessly collected and does not give the programmer the ability to unassign this object explicitly. The JAVA language does not pre-restrict any particular kind of valueless collection: various algorithms can be used depending on the needs of the system.

1.7 Method Area

Method regions are analogous to memory for compiled code in conventional languages or text segments in UNIX processors. It stores method code (compiled JAVA code) and symbolic data. In the current JAVA implementation, the method code is planned for public in the future but is not part of the worthless collection heap.

1.8 The JAVA Instruction Set

An instruction in the JAVA instruction set consists of a one-byte opcode that specifies the operation to be executed and zero or more operands that provide the parameters or data to be used by the operation. Many instructions have no operands and consist only of opcodes.

An inner loop of virtual machine execution is effective:

do {

Arithmetic patch

Execution of Action According to Operation Code

} while (more to do);

The number and size of additional operands is determined by the operation code. If the additional operand is more than one byte in size, it is stored in the big-endian order-high order byte first. For example, a 16-bit variable is stored as two bytes of the following value:

first＿byte * 256 + second＿byte

A bytecode instruction stream is just a byte sequence with execution, which is a table switch and lookup switch instruction arranged in 4-byte binary numbers within their instructions.

These decisions deflect conscious biases that keep the virtual machine code for the compiled compact JAVA program and compact any possible cost of execution.

1.9 Limitation

The constant pool per class has a maximum entry of 65535. This serves as an internal limitation of the overall complexity of a single class.

The amount of code per method is limited to 65535 bytes by the size of the index of the code in the anomaly table, line protection table, and local variable table.

In this limitation, the only other limitation of the annotation is the number of synonyms in the method call limited to 255.

2. Class File Format

This chapter describes the JAVA class (.class) file format.

Each class file contains a compiled version of a JAVA class or JAVA interface. Compile The JAVA interface must be able to handle all class files according to the following specification.

JAVA class files consist of an 8-bit byte stream. Both 16-bit and 32-bit are configured by reading into 16-bit or 32-bit bytes, respectively. The bytes are combined with a big-endian order that is high gytes come first. This format is supported by the JAVA.io.DataInput and JAVA.io.DataOutput interfaces and classes such as JAVA.io.DataInputStream and JAVA.io.DataOutpotStream.

Class file formats are described using structure notation. It is represented externally without any consecutively inserted insertion phrases or alignments within the structure. Variable size arrays, variable size elements are often called tables and are common locations within these structures.

Types u1, u2, and u4 mean the unsigned 1-, 2-, or 4-byte amounts, respectively, read by methods such as readUnsignedByte, readUnsignedShort, and readInt of the JAVA.io.DataInput interface.

2.1 Format

The following pseudo-structure describes the most important description of the format of a class file:

ClassFile {

          u4 magic;

          u2 minor_version;

          u2 major_version;

          u2 constant_pool_count;

          cp_info constant_pool [constant_pool_count-1];

          u2 access_flags;

          u2 this class;

          u2 super_class;

          u2 interfaces_count;

          u2 interfaces [interfaces_count];

          u2 fields_count;

          field_info fields [fields_count];

          u2 methods_count;

          method_info methods [methods_count];

          u2 attributes_count;

          attribute_info attribute [attribute_count];

}

magic

This field must have a value of 0xCAFEBABE.

minor_version, major_version

These fields contain the version number of the JAVA compiler that created these class files. Implementations of virtual machines will generally support some range of minor version numbers 0-n of a particular major version number. If the minor version number is incremented, the new code will not run on the old virtual machine, but it is possible to create a new virtual machine that can run up to n + 1 versions.

Changes in major version numbers indicate major incompatibilities that require other virtual machines that cannot support older major versions with any method.

The current major version number is 45; The minor version number is currently 3.

constant_pool_count

This field indicates the number of entries in the constant pool in the class file.

constant_pool

The constant pool is a table of values. These values are the string constants, class names, field names, etc. that are mentioned by the class structure or code.

constant_pool [0] is not always used by the compiler, but can be used for implementation for any purpose.

Each of the constant_pool [0] entries 1 through constant_pool_count-1 is a variable length entry given the format of the first " tag " byte as described in Section 2.3.

access_flags

This field contains a mask of up to 16 modifiers used in class, method, and field declarations. The same encoding is used on similar fields of field_info and method_info described below. Here is the encoding:

 Flag Name  value meaning Subject of use  ACC_PUBLIC  0x0001 Visible to all Classes, methods, variables  ACC_PRIVATE  0x0002 Visible only to defined classes Methods, variables  ACC_PROTECTED  0x0004 Visible to subclasses Methods, variables  ACC_STATIC  0x0008 Variable or method is static Methods, variables  ACC_FINAL  0x0010 No additional subclasses, nesting, or assignments after initialization Class, method, variable  ACC_SYNCHRONIZED  0x0020 Using Labs with Monitor Lock Method  ACC_VOLATILE  0x0040 Can't cache variable  ACC_TRANSIENT  0x0080 No writes or reads by the persistent object manager variable  ACC_NATIVE  0x0100 Implemented in languages other than JAVA Method  ACC_INTERFACE  0x0200 interface class  ACC_ABSTRACT  0x0400 No body provided Class, methods

this_class

This field is an index in the constant pool; constant_pool [this_class] must be CONSTANT_class.

super_class

This field is the index in the constant pool. If super_class is nonzero, constant_pool [super_class] must be a class, providing the index of the superclass of this class in the constant pool.

If the value of super_class is zero, the class defined must be JAVA.lang.Object and must not have any superclass.

interfaces_count

This field provides the number of interfaces this class implements.

interfaces

Each value in this table is an index in the constant pool. If the table value is nonzero (interface [i]! = 0 if 0≤i <interfaces_count), constant_pool [interfaces [i]] must be an interface implemented by this class.

fields_count

This field provides the number of example variables, both dynamic and static, defined by this class. The field table contains only variables that are implicitly defined by this class. It is accessible from this class but does not include those example variables inherited from the superclass.

fields

Each value in this table is a more complete description of the fields in the class. See Section 2.4 for more information about the field_info structure.

methods_count

This field indicates the number of static and dynamic methods defined by this class. This table contains only those methods implicitly defined by this class. Inherited methods are not included.

methods

Each value in this table is a more complete description of the methods in the class. See Section 2.5 for more information about the method_info structure.

attributes_count

This field indicates the number of additional attributes for this class.

attributes

A class can have any number of optional attributes associated with it. Currently, only recognized class attributes become "SourceFile" attributes, and the SourceFile attribute represents the name of the source file from which this class file is compiled.

2.2 signatures

The symbol is a string representing the type of an array, field or method.

The symbol field indicates the value of the variable or the argument to the function. It is a sequence of bytes generated by the following syntax:

<field_signature> :: = <field_type>

<field_type> :: = <base_type> | <object_type> | <array_type>

<base_type> :: = B | C | D | F | I | J | S | Z

<object_type> :: = L <fullclassname>;

<array_type> :: = <optional_size> <field_type>

<optional_size> :: = [0-9]

The meaning of the basic types is as follows:

B byte specified byte

C char character

D double double IEEE float

F float single-precision IEEE float

I int integer

J long double integer

L <fullclassname>; ... object of a given class

S short Specified single precision

Z boolean true or false

[<field sig> ... array

The return type symbol indicates the return of a value from a method. It is a sequence of bytes according to the following syntax:

<return_signature> :: = <field_type> | V

The letter V indicates that the method does not return any value. Otherwise, the symbol indicates the type of return value.

The argument symbol indicates the argument passed to the method:

<argument_signature> :: = <field_type>

Method symbols indicate the arguments that the method wants and the values that the method returns.

<method_signature> :: = (<arguments_signature>) <return_signature>

<arguments_signature> :: = <argument_signature> ^*

2.3 Constant Pool

Each item in the constant pool starts with a single byte tag. The table below lists valid tags and their values.

 Constant type     value  CONSTANT_Class CONSTANT_Fieldref CONSTANT_Methodref CONSTANT_InterfaceMethodref CONSTANT_String CONSTANT_Integer CONSTANT_Float CONSTANT_Long CONSTANT_Double CONSTANT_NameAndType CONSTANT_Utf8 CONSTANT_Unicode          7 9 10 11 8 3 4 5 6 12 1 2

Each tag byte then follows one or more bytes that provide additional information about the specified constant.

2.3.1 CONSTANT_Class

CONSTANT_Class is provided to represent a class or interface.

CONSTANT_Class_info {

     u1 tag;

     u2 name_index;

}

tag

The tag will have a value of CONSTANT_Class.

name_index

constant_pool [name_index] is CONSTANT_Utf8 giving the string name of the class.

Because the array is an object, the opcodes anewarray and multianewarray can refer to the array "classes" through the CONSTANT_Class item in the constant pool. In this case, the class name is its symbol. For example, the class name for int [] [] is [[I, the class name for Thread [] is "[LJAVA.lang.Thread;".

2.3.2 CONSTANT_ {Fieldref, Methodref, InterfaceMethodref}

Fields, methods, and interface methods are represented by similar structures.

CONSTANT_Fieldref_info {

    u1 tag;

    u2 class_index;

    u2 name_and_type_index;

}

CONSTANT_Methodref_info {

    u1 tag;

    u2 class_index;

    u2 name_and_type_index;

}

CONSTANT_InterfaceMethodref_info {

    u1 tag;

    u2 class_index;

    u2 name_and_type_index;

}

tag

The tag will have the values CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref.

class_index

constant_pool [class_index] will be an entry of type CONSTANT_Class that provides the interface or class name containing the field or method.

In CONSTANT_Fieldref and CONSTANT_Methodref, the CONSTANT_Class item must be a real class. In the CONSTANT_InterfaceMethodref, the item must be the supporting interface to implement the provided method.

name_and_type_index

constant_pool [name_and_type_index] will be an entry of type CONSTANT_NameAndType. This constant pool entry represents the symbol and name of the field or method.

2.3.3 CONSTANT_String

CONSTANT_String is used to represent a constant object of type string.

CONSTANT_String_info {

    u1 tag;

    u2 string_index;

}

tag

The tag will have a value of CONSTANT_String.

string_index

constant_pool [string_index] is a CONSTANT_utf8 string that provides the value from which the string object is initialized.

2.3.4 CONSTANT_Integer and CONSTANT_Float

CONSTANT_Integer and CONSTANT_Float represent 4-byte constants.

CONSTANT_Integer_info {

    u1 tag;

    u4 bytes;

}

CONSTANT_Float_info {

    u1 tag;

    u4 bytes;

}

tag

The tag will have a value of CONSTANT_Integer or CONSTANT_Float.

bytes

In integers, 4 bytes are integer values. In real terms, they are floating point values in the IEEE 754 standard representation. These bytes are in network order (high byte first).

2.3.5 CONSTANT_Long and CONSTANT_Double

CONSTANT_Long and CONSTANT_Double represent 8-byte constants.

CONSTANT_Long-info {

    u1 tag;

    u4 high_bytes;

    u4 low_bytes;

}

CONSTANT_Double_info {

    u1 tag;

    u4 high_bytes;

    u4 low_bytes;

}

Every 8-byte constant occupies two spots in the constant pool. If this is n ^th items in the constant pool, the next item will be numbered n + 2.

tag

The tag will have a value of CONSTANT_Long or CONSTANT_Double.

high_bytes, low_bytes

In CONSTANT_Long, the 64-bit value is (high_bytes << 32) + low_bytes.

In CONSTANT_Double, high_bytes and low_bytes of 64-bit values together represent double-precision floating point numbers of the standard IEEE 754 representation.

2.3.6 CONSTANT_NameAndType

CONSTANT_NameAndType is used to represent a field or method without indicating the class to which it belongs.

CONSTANT_NameAndType_info {

    u1 tag;

    u2 name_index;

    u2 signature_index;

}

tag

The tag will have a value of CONSTANT_NameAndType.

name_index

constant_pool [name_index] is a CONSTANT_Utf8 string that provides the field or method name.

signature_index

constant_pool [signature_index] is a CONSTANT_Utf8 string that provides the symbol of the field or method.

2.3.7 CONSTANT_Utf8 and CONSTANT_Unicode

CONSTANT_Utf8 and CONSTANT_Unicode are used to represent constant string values.

The CONSTANT_Utf8 string is "encoded" so that strings containing only non-empty ASCII characters can be displayed using only one byte per character, but up to 16-bit characters can be displayed.

All characters in the range 0x0001 to 0x007F are represented by one byte:

Empty characters (0x0000) and characters in the range 0x0080 to 0x07FF are represented by a pair of two bytes.

Characters in the range 0x0800 to 0xFFFF are represented by 3 bytes:

There are two differences between this format and the "standard" UTF-8 format. First, empty bytes (0x00) are encoded in a two-byte format rather than one, so that the string does not have a space. Second, only 1 byte, 2 byte and 3 byte formats are used. Longer formats are not recognized.

CONSTANT_Utf8_info {

    u1 tag;

    u2 length;

    u1 bytes [length];

}

CONSTANT_Unicode_info {

    u1 tag;

    u2 length;

    u2 bytes [length];

}

tag

The tag will have a value of CONSTANT_Utf8 or CONSTANT_Unicode.

length

Number of bytes in string. These strings are not empty spaces.

bytes

The actual byte of the string.

2.4 Fields

The information for each field immediately follows the field_count field in the class file. Each field is described by a variable length field_info structure. The format of this structure is as follows:

field_info {

     u2 access_flags;

     u2 name_index;

     u2 signature_index;

     u2 attributes_count;

     attribute_info attributes [attribute_count];

}

access_flags

This is a set of 16 flags used by classes, methods, and fields to describe the various properties and methods they can access by methods in other classes.

Possible fields that can be set for the field are ACC_PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC, ACC_FINAL, ACC_VOLATILE, and ACC_TRANSIENT.

At least one of ACC_PUBLIC, ACC_PROTECTED and ACC_PRIVATE may be set for any method.

name_index

constant_pool [name_index] is a field name CONSTANT_Utf8.

signature_index

constant_pool [signature_index] is a CONSTANT_Utf8 string that is a field symbol. See the "Symbols" chapter for more information about symbols.

attributes_count

This value indicates the number of additional attributes for this field.

attributes

A field can have any number of optional attributes associated with it. Currently, only recognized field attributes become "ConstantValue" attributes, and the ConstantValue attribute indicates that this field is a static constant and indicates the constant value of that field.

Any other attribute is skipped.

2.5 Methods

The information for each method immediately follows the method_count field in the class file. Each method is described by a variable length method_info structure. The structure has the following format:

method_info {

      u2 access_flags;

      u2 name_index;

      u2 signature_index;

      u2 attributes_count;

      attribute_info attributes [attribute_count];

}

access_flags

This is a set of 16 flags used by classes, methods, and fields to describe the various properties and methods they can access by methods in other classes. See the "Access Flags" table for providing various bits in this field.

Possible fields that can be set for the method are ACC_PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC, ACC_FINAL, ACC_SYNCHRONIZED, ACC_NATIVE, and ACC_ABSTRACT.

At least one of ACC_PUBLIC, ACC_PROTECTED and ACC_PRIVATE may be set for any method.

name_index

constant_pool [name_index] is a CONSTANT_Utf8 string that provides the method name.

signature_index

constant_pool [signature_index] is a CONSTANT_Utf8 string that provides the field symbol. See the "Symbols" chapter for more information about symbols.

attributes_count

This value indicates the number of additional attributes for this field.

attributes

A field can have any number of optional attributes associated with it. Each attribute has a name and other additional information. Currently, only recognized field attributes become "Code" and "Exceptions" attributes, and the Code and Exceptions attributes describe the JAVA exceptions declared to be the bytecode executed to perform this method and the execution result of the method, respectively.

Any other attribute is skipped.

2.6 Attributes

Attributes are used in different places in the class format. All properties have the following format:

GenericAttribute_info {

     u2 attribute_name;

     u4 attribute_length;

     u1 info [attribute_length];

}

attribute_name is a 16-bit index in the constant pool of the class; The value of constant_pool [attribute_name] is a CONSTANT_Utf8 string that provides the attribute name. The field attribute_length indicates the length of subsequent information in bytes. This length does not include attribute_name and attribute_length of 6 bytes.

In the following text, each time you accept an attribute, you provide the attribute name currently understood. In the future, more attributes will be added. Class file readers are required to skip and ignore information in any attributes they do not understand.

2.6.1 SourceFile

The "SourceFile" property has the following format:

SourceFile_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 sourcefile_index;

}

attribute_name_index

constant_pool [attribute_name_index] is the CONSTANT_Utf8 string "SourceFile".

attribute_length

The length of the SourceFile_attribute must be 2.

sourcefile_index

constant_pool [sourcefile_index] is the CONSTANT_Utf8 string that provides the source file from which this class file was compiled.

2.6.2 ConstantValue

The "ConstantValue" attribute has the following format:

ConstantValue_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 constantvalue_index;

}

attribute_name_index

constant_pool [attribute_name_index] is the CONSTANT_Utf8 string "ConstantValue".

attribute_length

The length of ConstantValue_attribute must be 2.

constantvalue_index

constant_pool [constantvalue_index] provides a constant value for this field.

The constant pool entry must be one of the appropriate types for the field, as shown in the following table.

 long  CONSTANT_Long  float  CONSTANT_Float  double  CONSTANT_Double  int, short, char, byte, boolean  CONSTANT_Integer

2.6.3 Code

The "Code" attribute has the following format:

Code_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 max_stack;

     u2 max_locals;

     u4 code_length;

     u1 code [code_length];

     u2 exception_table_length;

     {u2 start_pc;

          u2 end_pc;

          u2 handler_pc;

          u2 catch_type;

     } exception_table [exception_table_length];

     u2 attributes_count;

     attribute_info attributes [attribute_count];

}

attribute_name_index

constant_pool [attribute_name_index] is the CONSTANT_Utf8 string "Code".

attribute_length

This field indicates the total length of the "Code" attribute excluding the initial 6 bytes.

max_stack

Maximum number of entries on the operand stack to be used during the execution of this method. See other chapters in this specification for additional information on operand stacks.

max_locals

Number of local variable slots used by this method. See other chapters in this document for additional information on local variables.

code_length

Number of bytes in virtual machine code for this method.

code

These are the actual bytes of the virtual machine code that implement the method. When reading memory, if the first byte of code is aligned on four multiple boundaries, the opcode entries tableswitch and tablelookup will be aligned; See the description of it for more information about the sort request.

exception_table_length

Number of entries in the next exception table.

exception_table

Each entry in the exception table describes one exception handler in the code.

start_pc, end_pc

Two fieldsstart_pc and end_pc indicate the range in the code where the exception handler is active. The values in both fields are offsets from the beginning of the code. start_pc is included and end_pc is excluded.

handler_pc

This field indicates the start address of the exception handler. The field value is the offset from the beginning of the code.

catch_type

If catch_type is nonzero, constant_pool [catch_type] will be the exception class that this exception handler is designed to catch. This exception handler should only be called if the exception thrown is an example of a given class.

If catch_type is zero, this exception handler should be called on every exception.

attributes_count

This field indicates the number of additional attributes for the code. The "Code" attribute may itself have an attribute.

attributes

The "Code" attribute can have any number of optional attributes associated with it. Each attribute has a name and other additional information. Currently, the defined code attributes are only "LineNumberTable" and "LocalVariableTable" and both contain debugging information.

2.6.4 Exception Table

This table is used by the compiler to indicate the exception that the method declares to execute.

Exceptions_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 number_of_exceptions;

     u2 exception_index_table [number_of_exceptions];

}

attribute_name_index

constant_pool [attribute_name_index] will be the CONSTANT_Utf8 string "Exceptions".

attribute_length

This field indicates the total length of Exceptions_attribute excluding the initial 6 bytes.

number_of_exceptions

This field indicates the number of entries in the following exception index table.

exception_index_table

Each value in this table is an index in the constant pool. For each table element, if (0 ≤ I <number_of_exceptions exception_index_table [i]! = 0), constant_pool [exception_index + table [i]] is the exception that this class declares to execute.

2.6.5 LineNumberTable

This property is used by debuggers and exception handlers to determine that a portion of virtual machine code corresponds to a given location in the source. LineNumberTable_attribute has the following format:

LineNumberTable_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 line_number_table_length;

     {u2 start_pc;

     u2 line_number;

     } line_number_table [line_number_table_length];

}

     u2 exception_index_table [number_of_exceptions];

}

attribute_name_index

constant_pool [attribute_name_index] will be the CONSTANT_Utf8 string "LineNumberTable".

attribute_length

This field indicates the total length of LineNumberTable_attribute excluding the initial 6 bytes.

line_number_table_length

This field indicates the number of entries in the next line count table.

line_number_table

Each entry in the line count table indicates that the number of lines in the source file changes at a given point in the code.

start_pc

This field indicates where in the code the code for the new line in the source begins. source_pc << SHOULD THAT BEstart_pc? >> is the offset from the beginning of the code.

line_number

The number of lines starting at a given position in the file.

2.6.6 LocalVariableTable

This property is used by the debugger to determine the value of a given local variable during the dynamic execution of a method. The format of LocalVariableTable_attribute is:

LocalVariableTable_attribute {

     u2 attribute_name_index;

     u4 attribute_length;

     u2 local_variable_table_length;

     {u2 start_pc;

           u2 length;

           u2 name_index;

           u2 signature_index;

           u2 slot;

     } local_variable_table [local_variable_table_length];

}

attribute_name_index

constant_pool [attribute_name_index] will be the CONSTANT_Utf8 string "LocalVariableTable".

attribute_length

This field indicates the total length of LineNumberTable_attribute excluding the initial 6 bytes.

local_variable_table_length

This field indicates the number of entries in the next local variable table.

local_variable_table

Each entry in the local variable table represents its code range while the local variable has a value. It also represents the value on which the variable can be found on the stack.

start_pc, length

The given local variable has a value in the code between start_pc and start_pc + length. Both values are offset from the beginning of the code.

name_index, signature_index

constant_pool [name_index] and constant_pool [signature_index] are CONSTANT_Utf8 strings that provide the names and symbols of local variables.

slot

The given variable will be the slot ^th local variable in the method's frame.

3. The Virtual Machine Instruction Set

3.1 Format for Command

JAVA virtual machine instructions are represented herein as entries of the following types.

instruction name

Brief description of the command

construction:

Opcode = number operand1 operand2 ...

Stack: ...., value1, value2 => ..., value3

A longer description describing the function of the command and indicating any exceptions that may be thrown during execution.

Each line in the syntax table represents a single 8-bit byte.

Operations in JAVA virtual machines often take their operands from the stack and put the results back on the stack. As a rule, we will not mention here the case where the stack is the source or end of the operation, but otherwise it will always be mentioned. For example, the command iload has a short description to "load an integer from a local variable". Implicitly, integers are loaded onto the stack. The command iadd is described as "integer addition"; Both the source and the end are stacks.

An instruction that does not affect the control flow of the calculation may be assumed to always advance the virtual machine program counter with the opcode of the next instruction. Only instructions that affect the control flow will implicitly mention their effect on the program counter.

3.2 Pushing Constants onto the Stack

bipush

Single-byte signed integer push

construction:

bipush = 16 byte1

Stack: ... => ..., value

byte1 is interpreted as a signed 8-bit value. This value is expanded to an integer and pushed onto the operand stack.

sipush

2-byte signed integer push

construction:

sipush = 17 byte1 byte2

Stack: ... => ..., item

byte1 byte2 and is assembled with a signed 16-bit value. This value is expanded to an integer and pushed onto the operand stack.

ldc1

Push items from constant pool

construction:

ldc1 = 18 indexbyte1

Stack: ... => ..., item

indexbyte1 is used as an unsigned 8-bit index into the constant pool of the current class. The item at that index is resolved and pushed onto the stack. If a string is being pushed and there is not enough memory to allocate it, an OutOfMemoryError is called.

Note : String Push lets you do object references.

ldc2

Push items from constant pool

construction:

ldc2 = 19 indexbyte1 indexbyte2

Stack: ... => ..., item

indexbyte1 and indexbyte2 are used to construct an unsigned 16-bit index into the constant pool of the current class. The item at that index is resolved and pushed onto the stack. If a string is being pushed and there is not enough memory to allocate it, an OutOfMemoryError is called.

Note : String Push lets you do object references.

ldc2w

Push long or double from constant pool

construction:

ldc2w = 20 indexbyte1 indexbyte2

Stack: ... => ..., constant-word1, constant-word2

indexbyte1 and indexbyte2 are used to construct an unsigned 16-bit index into the constant pool of the current class. The two word constant at that index is solved and pushed onto the stack.

aconst_null

Push empty object reference

construction:

aconst_null = 1

Stack: ... => ..., null

Push an empty object reference onto the stack.

iconst_m1

Integer constant-1 push

construction:

iconst_ml = 2

Stack: ... => ..., 1

Push integer-1 onto the stack.

iconst_ <n>

Integer constant push

construction:

iconst_ <n>

Stack: ... => ..., <n>

Type: iconst_0 = 3, iconst_1 = 4, iconst_2 = 5, iconst_3 = 6, iconst_4 = 7, iconst_5 = 8

Push integer <n> onto stack.

lconst_ <l>

Double integer constant push

construction:

lconst_ <l>

Stack: ... => ..., <l> -word1, <l> -word2

Type: lconst_0 = 9, lconst_1 = 10

Push a double integer <l> onto the stack.

fconst_ <f>

Single precision floating point push

construction:

fconst_ <f>

Stack: ... => ..., <f>

Type: fconst_0 = 11, fconst_1 = 12, fconst_2 = 13

Push a single floating point number <f> onto the stack.

dconst_ <d>

Double precision floating point push

construction:

dconst_ <d>

Stack: ... => ..., <d> -word1, <d> -word2

Type: dconst_0 = 14, dconst_1 = 15

Push double precision floating point number <d> onto stack.

3.3 Loading Local Variables Onto the Stack

lload

Load integer from local variable

construction:

iload = 21 vindex

Stack: ... => ..., value

The value of the local variable at vindex in the current JAVA frame is pushed onto the operand stack.

iload_ <n>

Push integers from local variables

construction:

iload_ <n>

Stack: ... => ..., value

Type: iload_0 = 26, iload_1 = 27, iload_2 = 28, iload_3 = 29

The value of the local variable in <v> in the current JAVA frame is pushed onto the operand stack.

This command is the same as in iload with vindex of <n> , except that operand <n> is implicit.

iload

Load long integer from local variable

construction:

iload = 22 vindex

Stack: ... => ..., value-word1, value-word2

The values of local variables at vindex and vindex + 1 in the current JAVA frame are pushed onto the operand stack.

lload_ <n>

Load long integer from local variable

construction:

iload_ <n>

Stack: ... => ..., value-word1, value-word2

Type: lload_0 = 30, lload_1 = 31, lload_2 = 32, lload_3 = 33

The values of local variables at <n> and <n> +1 in the current JAVA frame are pushed onto the operand stack.

This command is the same as in lload with vindex of <n> except that operand <n> is implicit.

fload

Load single-precision floating point from local variable

construction:

fload = 23 vindex

Stack: ... => ..., value

The value of the local variable at vindex in the current JAVA frame is pushed onto the operand stack.

fload_ <n>

Load single-precision floating point from local variable

construction:

fload_ <n>

Stack: ... => ..., value

Type: fload_0 = 34, fload_1 = 35, fload_2 = 36, fload_3 = 37

The value of the local variable in <n> in the current JAVA frame is pushed onto the operand stack.

This command is the same as in fload with vindex of <n> except that operand <n> is implicit.

dload

Load double float from local variable

construction:

dload = 24 vindex

Stack: ... => ..., value-word1, value-word2

The values of local variables at vindex and vindex + 1 in the current JAVA frame are pushed onto the operand stack.

dload_ <n>

Load double float from local variable

construction:

dload_ <n>

Stack: ... => ..., value-word1, value-word2

Type: dload_0 = 38, dload_1 = 39, dload_2 = 40, dload_3 = 41

The values of local variables at <n> and <n> +1 in the current JAVA frame are pushed onto the operand stack.

This command is the same as in dload with vindex of <n> , except that operand <n> is implicit.

aload

Load object reference from local variable

construction:

aload = 25 vindex

Stack: ... => ..., value

The value of the local variable at vindex in the current JAVA frame is pushed onto the operand stack.

aload_ <n>

Load object reference from local variable

construction:

aload_ <n>

Stack: ... => ..., value

Type: aload_0 = 42, aload_1 = 43, aload_2 = 44, aload_3 = 45

The value of the local variable in <n> in the current JAVA frame is pushed onto the operand stack.

This command is the same as in aload with vindex of <n> , except that operand <n> is implicit.

3.4 Storing Stack Values as Local Variables

istore

Store integers as local variables

construction:

istore = 54 vindex

Stack: ..., value => ...

value must be an integer. The local variable vindex in the current JAVA frame is set to a value.

istore_ <n>

Store integers as local variables

construction:

istore_ <n>

Stack: ..., value => ...

Type: istore_0 = 59, istore_1 = 60, istore_2 = 61, istore_3 = 62

value must be an integer. The local variable <n> in the current JAVA frame is set to value .

This command is the same as in istore with vindex of <n> , except that operand <n> is implicit.

lstore

Store long integer as local variable

construction:

lstore = 55 vindex

Stack: ..., value-word1, value-word2 => ...

value must be a long integer. The local variable vindex + 1 in the current JAVA frame is set to value .

lstore_ <n>

Store long integer as local variable

construction:

lstore_ <n>

Stack: ..., value-word1, value-word2 =>

Type: lstore_0 = 63, lstore_1 = 64, lstore_2 = 65, lstore_3 = 66

value must be an integer. The local variables <n> and <n> +1 in the current JAVA frame are set to value .

This command is the same as in lstore with vindex of <n> except that operand <n> is implicit.

fstore

Store single-precision floating point as local variable

construction:

fstore = 56 vindex

Stack: ..., value => ...

value must be a single floating point number. The local variable vindex in the current JAVA frame is set to value .

fstore_ <n>

Store single-precision floating point as local variable

construction:

fstore_ <n>

Stack: ..., value => ...

Type: fstore_0 = 67, fstore_1 = 68, fstore_2 = 69, fstore_3 = 70

value must be a single floating point number. The local variable <n> in the current JAVA frame is set to value .

This command is the same as in fstore with vindex of <n> , except that operand <n> is implicit.

dstore

Store double float as local variable

construction:

dstore = 57 vindex

Stack: ..., value-word1, value-word2 => ...

value must be a double-precision floating point number. The local variables vindex and vindex + 1 in the current JAVA frame are set to value .

dstore_ <n>

Store double float as local variable

construction:

dstore_ <n>

Stack: ..., value-word1, value-word2 => ...

Type: dstore_0 = 71, dstore_1 = 72, dstore_2 = 73, dstore_3 = 74

value must be a double-precision floating point number. The local variables <n> and <n> +1 in the current JAVA frame are set to value .

This command is the same as in dstore with vindex of <n> , except that operand <n> is implicit.

astore

Save object reference as local variable

construction:

astore = 58 vindex

Stack: ..., value => ...

value must be a reference to a return address or object. The local variable vindex in the current JAVA frame is set to value .

astore_ <n>

Save object reference as local variable

construction:

astore_ <n>

Stack: ..., value => ...

Type: astore_0 = 75, astore_1 = 76, astore_2 = 77, astore_3 = 78

value must be a reference to a return address or object. The local variable <n> in the current JAVA frame is set to a value.

This command is the same as in astore with vindex of <n> , except that operand <n> is implicit.

iinc

Increment local variable by constant

construction:

iinc = 132 vindex const

Stack: no change

The local variable vindex in the current JAVA frame must contain an integer. If const is treated as a signed 8-bit quantity, it is incremented by the value of const .

3.5 Wider Index for Load, Save and Increase

wide

Wider index for accessing local variables in load, store, and increment.

construction:

wide = 196 vindex2

Stack: No change

This bytecode must precede one of the following bytecodes: iload, lload, fload, dload, aload, istore, lstore, fstore, dstore, astore, iinc. Vindex of the next bytecode and vindex2 from this bytecode are assembled into an unsigned 16-bit index into a local variable in the current JAVA frame. The following bytecodes operate normally except for the use of this wider index.

3.6 Managing Arrays

newarray

New Array Allocation

construction:

newarray = 196 atype

Stack: ..., size => result

size must be an integer. It represents the number of elements in the new array.

atype is an internal code indicating the type of array to be allocated. Possible values for atype are:

T_BOOLEAN 4

T_CHAR 5

T_FLOAT 6

T_DOUBLE 7

T_BYTE 8

T_SHORT 9

T_INT 10

T_LONG 11

A new array atype is allocated that can hold size elements, and result is a reference to this new object. An allocation of an array large enough to contain a size item of atype is attempted. All elements of the array are initialized to zero.

If size is less than zero, NegativeArraySizeExecution is invoked. If there is not enough memory to allocate the array, OutOfMemoryError is triggered.

anewarray

Assign a new reference array to the object

construction:

anewarray = 189 indexbyte1 indexbyte2

Stack: ..., size => result

size must be an integer. It represents the number of elements in the new array.

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index is resolved. The resulting entry must be a class.

A new array of the indicated class type, which can hold size elements, is allocated and result is a reference to this new object. An allocation of an array large enough to contain a size item of a given class type is attempted. All elements of the array are initialized to empty.

If size is less than zero, NegativeArraySizeExecution is invoked. If there is not enough memory to allocate the array, OutOfMemoryError is triggered.

anewarray is used to create a one-dimensional array of object references. For example, to create a new Thread [7], the following code is used:

bipush 7

anewarray <Class "JAVA.lang.Thread">

anewarray can also be used to create a multidimensional array of first dimensions. For example, the array declaration looks like this:

new int [6] []

This can be generated with code like this:

bipush 6

anewarray <Class "[I">

See CONSTANT_Class in the "Class File Format" chapter for information on array class names.

multianewarray

New multidimensional array allocation

construction:

multianewarray = 197 indexbyte1 indexbyte2 dimensions

Stack: ..., size1, size2 ... sizen => result

Each size must be an integer. Each represents the number of elements in the dimensions of the array.

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index is resolved. The resulting entry must be an array class of one or more dimensions.

dimensions have the following characteristics:

Must be an integer greater than or equal to 1.

Indicates the number of dimensions to be created. Must be less than or equal to the number of dimensions of the array class.

Shows the number of elements popped from the stack. All must be an integer greater than or equal to zero. Used with the size of the dimension.

For example, to generate new int [6] [3] [], the following code is used:

bipush 6

bipush 3

multianewarray <Class "[[[I"> 2

If one of the size arguments on the stack is less than zero, NegativeArraySizeExecution is invoked. If there is not enough memory to allocate the array, OutOfMemoryError is triggered.

result is a reference to the new array object.

Note : If you are creating one dimension, it is more than enough to use newarray or anewarray.

For information on array class names, see CONSTANT_Class in the "Class File Format" chapter.

arraylength

Find the length of the array

construction:

arraylength = 190

Stack: ..., objectref => ..., length

objectref must be a reference to an array object. The length of the array is determined and the objectref is replaced at the top of the stack.

If objectref is null, a NullPointerException is thrown .

iaload

Load integer from array

construction:

iaload = 46

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to an array of integers. index must be an integer. The integer value at position number index in the array is retrieved and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

laload

Load double integer from array

construction:

laload = 47

Stack: ..., arrayref, index => ..., value-word1, value-word2

arrayref must be a reference to a double integer array. index must be an integer. The double integer value at position number index in the array is retrieved and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

faload

Single-precision floating point load from array

construction:

faload = 48

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to a single-precision floating point array. index must be an integer. The single-precision floating point value at position number index in the array is retrieved and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

daload

Load a double float from an array

construction:

daload = 49

Stack: ..., arrayref, index => ..., value-word1, value-word2

arrayref must be a reference to a double-precision floating point array. index must be an integer. The double-precision floating-point value at position number index in the array is retrieved and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

aaload

Load object reference from array

construction:

aaload = 50

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to an object reference array. index must be an integer. The object reference at position number index in the array is retrieved and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

baload

Load Signed Byte From Array

construction:

baload = 51

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to a signed byte array. index must be an integer. The signed byte value at position number index in the array is retrieved, expanded to an integer, and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

caload

Load character from array

construction:

caload = 52

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to an array of characters. index must be an integer. The character value at position number index in the array is retrieved, zero-extended to an integer, and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

saload

Single precision load from array

construction:

saload = 53

Stack: ..., arrayref, index => ..., value

arrayref must be a reference to a single integer array. index must be an integer. The signed single integer value at position number index of the array is retrieved, expanded to an integer, and pushed to the top of the stack.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

iastore

Store as an integer array

construction:

iastore = 79

Stack: ..., arrayref, index, value => ...

arrayref must be a reference to an array of integers. index must be an integer and value must be an integer. The integer value is stored at position index in the array.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

lastore

Store as a double integer array

construction:

lastore = 80

Stack: ..., arrayref, index, value-word1, value-word2 => ...

arrayref must be a reference to an array of double integers, index must be an integer, and value must be a double integer. The double integer value is stored at position index in the array.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

fastore

Store as single-precision floating point array

construction:

fastore = 81

Stack: ..., arrayref, index, value => ...

arrayref must be a reference to an array of single-precision floating point numbers, index must be an integer, and value must be a single precision floating point number. Single-precision floating point values are stored at position index in the array.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

dastore

Stored in double-precision floating point array

construction:

dastore = 82

Stack: ..., arrayref, index, value-word1 , value-word2 => ...

arrayref must be a reference to an array of double precision floating point numbers, index must be an integer, and value must be a double precision floating point number. Double-precision floating-point values are stored at position index in the array.

If arrayref is null, a NullPointerException is thrown . If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

aastore

Save as Object Reference Array

construction:

aastore = 83

Stack: ..., arrayref, index, value => ...

arrayref must be a reference to an object reference array, index must be an integer, and value must be an object reference. The object reference value is stored at position index in the array.

If arrayref is null, a NullPointerException is thrown . If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked. The actual type of value must match the actual type of the array element. For example, storing an example of a class Thread in a class Object array is valid, but not otherwise. An ArrayStoreException is thrown when an attempt is made to store an incompatible object reference.

bastore

Store as signed byte array

construction:

bastore = 84

Stack: ..., arrayref, index, value => ...

arrayref must be a reference to a signed byte array, index must be an integer, and value is an integer. The integer value is stored at position index in the array. If value is too large to be a signed byte, it is truncated.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

castore

Save as character array

construction:

castore = 85

Stack: ..., arrayref, index, value => ...

arrayref must be an array of characters, index must be an integer, and value is an integer. The integer index is stored at position index of the array. If value is too large to be a character, it is truncated.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

sastore

Store in single precision array

construction:

sastore = 86

Stack: ..., arrayref, index, value => ...

arrayref must be a single array, index must be an integer, and value is an integer. The integer value is stored at the position index of the array. If value is too large to be short, it is truncated.

If arrayref is null, a NullPointerException is invoked. If index is not within the bounds of the array, an ArrayIndexOutOfBoundsException is invoked.

3.7 Stack Instructions

nop

Nothing to do

construction:

nop = 0

Stack: no change

Nothing to do.

pop

Top Stack Word Pop

construction:

pop = 87

Stack: ..., any => ...

Pop the top word from the stack.

pop2

Top Two Stacks Wordpop

construction:

pop2 = 89

Stack: ..., any2, any1 => ...

Pop the top two words from the stack.

dup

Copy top stack word

construction:

dup = 89

Stack: ..., any => ..., any, any

Copies the highest word on the stack.

dup2

Top Two Stack Word Copy

construction:

dup2 = 92

Stack: ..., any2, any1 => ..., any2, any1, any2, any1

Copies the top two words on the stack.

dup_x1

Copies the top stack word and puts two

construction:

dup_x1 = 90

Stack: ..., any2, any1 => ..., any1, any2, any1

Copies the highest word on the stack and inserts the two words copied into the stack.

dup2_x1

Copies the top two stack words and puts them down

construction:

dup_x1 = 93

Stack: ..., any3, any2, any1 => ..., any2, any1, any3, any2, any1

Copy the top two words on the stack and insert the two words copied into the stack.

dup_x2

Copy the top stack word and put three down

construction:

dup_x2 = 91

Stack: ..., any3, any2, any1 => ..., any1, any3, any2, any1

Copies the highest word on the stack and inserts three words copied into the stack.

dup2_x2

Copy the top two stack words and put three down

construction:

dup2_x2 = 94

Stack: ..., any4, any3, any2, any1 => ..., any2, any1, any4, any3, any2, any1

Copy the top two words on the stack and insert the three words copied into the stack.

swap

Swap the top two stack words

construction:

swap = 95

Stack: ..., any2, any1 => ..., any2, any1

Swap the top two components on the stack.

3.8 Arithmetic Instructions

iadd

Integer addition

construction:

iadd = 96

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. The values are added and replaced on the stack by their sum of integers.

ladd

Double precision addition

construction:

ladd = 97

Stack: ..., value1-word1, value1-word2, value2-word2 => ..., result-word2

value1 and value2 must be integers. The values are added and replaced on the stack by their double integer sum.

fadd

Single precision floating point addition

construction:

fadd = 98

Stack: ..., value1, value2 => ..., result

value1 and value2 must be single-precision floating point numbers. The values are added and replaced on the stack by their single floating point sum.

dadd

Double precision floating point addition

construction:

dadd = 99

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double-precision floating point numbers. The values are added and replaced on the stack by their double precision floating point sum.

isub

Integer Subtraction

construction:

isub = 100

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. value2 is subtracted from value1 and both values are replaced on the stack by their integer difference.

lsub

Double precision subtraction

construction:

lsub = 101

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double integers. value2 is subtracted from value1 , and both values are replaced on the stack by their double integer difference.

fsub

Single precision floating point subtraction

construction:

fsub = 102

Stack: ..., value1, value2 => ..., resul t

value1 and value2 must be single-precision floating point numbers. value2 is subtracted from value1 , and both values are replaced on the stack by their single precision floating point difference.

dsub

Double precision floating point subtraction

construction:

dsub = 103

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double-precision floating point numbers. value2 is subtracted from value1 and both values are replaced on the stack by their double precision floating point difference.

imul

Integer multiplication

construction:

imul = 104

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. Both values are replaced on the stack by their integer product.

lmul

Double integer multiplication

construction:

imul = 105

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double integers. Both values are replaced on the stack by their double integer product.

fmul

Single precision floating point multiplication

construction:

fmul = 106

Stack: ..., value1, value2 => ..., result

value1 and value2 must be single-precision floating point numbers. Both values are replaced on the stack by their single floating point product.

dmul

Double precision floating point multiplication

construction:

dmul = 107

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double-precision floating point numbers. Both values are replaced on the stack by their double precision floating point product.

idiv

Integer Division

construction:

idiv = 108

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. value1 is divided by value2 , and both values are replaced on the stack by their integer quotient.

The result is truncated to the nearest integer between it and zero. Attempts to divide by zero result in a "/ by zero" ArithmeticException being invoked.

ldiv

Double integer division

construction:

ldiv = 109

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double integers. value1 is divided by value2 , and both values are replaced on the stack by their double integer quotient.

The result is truncated to the nearest integer between it and zero. Attempts to divide by zero result in a "/ by zero" ArithmeticException being invoked.

fdiv

Single precision floating point division

construction:

fdiv = 110

Stack: ..., value1, value2 => ..., result

value1 and value2 must be single-precision floating point numbers. value1 is divided by value2 , and both values are replaced on the stack by their single floating point quotient.

Dividing by 0 gives the quotient NaN.

ddiv

Double-precision floating point division

construction:

ddiv = 111

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double-precision floating point numbers. value1 is divided by value2 , and both values are replaced on the stack by their double-precision floating point quotient.

Dividing by 0 gives the quotient NaN.

irem

Integer remainder

construction:

irem = 112

Stack: ..., value1, value2 => ..., result

value1 and value2 must both be integers. value1 is divided by value2 , and both values are replaced on the stack by their integer remainder.

Attempts to divide by zero result in a "/ by zero" ArithmeticException being invoked.

lrem

Double integer remainder

construction:

lrem = 113

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must both be double integers. value1 is divided by value2 , and both values are replaced on the stack by their double integer remainder.

Attempts to divide by zero result in a "/ by zero" ArithmeticException being invoked.

frem

Single precision floating point remainder

construction:

frem = 114

Stack: ..., value1, value2 => ..., result

value1 and value2 must both be single-precision floating point numbers. value1 is divided by value2 , and the quotient is truncated to an integer. The product is subtracted from value1 . As a result, both values are swapped on the stack, such as single precision floating point numbers.

result = value1- (integral_part (value / value2) * value2 ), where integral_part () rounds to the nearest integer with the same number being even.

If you divide by zero, the result is NaN.

drem

Double precision floating point remainder

construction:

drem = 115

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must both be double-precision floating point numbers. value1 is divided by value2 , the quotient is truncated to an integer, and then multiplied by value2 . The product is subtracted from value1 . As a result, both values, such as double precision floating point numbers, are swapped on the stack.

result = value1- (integral_part (value / value2) * value2 ), where integral_part () rounds to the nearest integer with the same number being even.

If you divide by zero, the result is NaN.

ineg

Integer indirect

construction:

ineg = 116

Stack: ..., value => ..., result

value must be an integer. This is put on the stack by its arithmetic operation indirectly.

lneg

Double integer indirect

construction:

lneg = 117

Stack: ..., value1-word1, value1-word2 => ..., result-word1

value must be an integer. This is put on the stack by its arithmetic operation indirectly.

fneg

Single-precision floating point indirect

construction:

fneg = 118

Stack: ..., value => ..., result

value must be a single floating point number. This is put on the stack by its arithmetic operation indirectly.

dneg

Double precision floating point indirect

construction:

dneg = 119

Stack: ..., value1-word1, value1-word2 => ..., result-word1, result-word2

value must be a double-precision floating point number. It is placed on the stack by its arithmetic operation indirectly.

3.9 Logical Instructions

ishl

Integer left shift

construction:

ishl = 120

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. value1 is shifted left by the amount indicated by the lower 5 bits of value2 . The integer result puts both values on the stack.

ishr

Integer Arithmetic Right Shift

construction:

ishr = 122

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. value1 is shifted arithmetic right (with sign extension) by the amount indicated by the lower 5 bits of value2 . The integer result puts both values on the stack.

iushr

Integer Logic Right Shift

construction:

iushr = 124

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. value1 is shifted arithmetic right (without sign expansion) by the amount indicated by the lower 5 bits of value2 . The integer result puts both values on the stack.

lshl

Double integer left shift

construction:

lshl = 121

Stack: ..., value1-word1, value1-word2, value2 => ..., result-word1, result-word2

value1 must be a double integer and value2 must be an integer. value1 is shifted left by the amount indicated by the lower 6 bits of value2 . The double integer result puts both values on the stack.

lshr

Double-precision integer arithmetic right shift

construction:

lshr = 123

Stack: ..., value1-word1, value1-word2, value2 => ..., result-word1, result-word2

value1 must be a double integer and value2 must be an integer. value1 is shifted arithmetic right (with sign extension) by the amount indicated by the lower 6 bits of value2 . The double integer result puts both values on the stack.

lushr

Double Integer Logic Right Shift

construction:

lushr = 125

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 must be a double integer and value2 must be an integer. value1 is logically shifted right (without sign extension) by the amount indicated by the lower 6 bits of value2 . The double integer result puts both values on the stack.

iand

Integer Boolean AND

construction:

iand = 126

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. These are placed on the stack by their bitwise logic and.

land

Double integer integer AND

construction:

land = 127

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double integers. These are placed on the stack by their bitwise logic and.

ior

Integer Boolean OR

construction:

ior = 128

Stack: ..., value1, value2 => ..., result

value1 and value2 must be integers. These are placed on the stack by their bitwise logic or.

lor

Double integer Boolean OR

construction:

lor = 129

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must be double integers. These are placed on the stack by their bitwise logic or.

ixor

Integer Boolean XOR

construction:

ixor = 130

Stack: ..., value1, value2 => ..., result

value1 and value2 must both be integers. They are placed on the stack by their bitwise exclusive or.

lxor

Double Integer Boolean XOR

construction:

lxor = 131

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result-word1, result-word2

value1 and value2 must both be double integers. They are placed on the stack by their bitwise exclusive or.

3.10 Conversion Operations

i2l

Integer-double integer conversion

construction:

i2l = 133

Stack: ..., value => ..., result-word1, result-word2

value must be an integer. This is converted to a double integer. The result replaces value on the stack.

i2f

Integer-precision floating point

construction:

i2f = 134

Stack: ..., value => ..., result

value must be an integer. This is converted to a single floating point number. The result replaces value on the stack.

i2d

Integer-double floating point

construction:

i2d = 135

Stack: ..., value => ..., result-word1, result-word2

value must be an integer. This is converted to a double precision floating point number. The result replaces value on the stack.

l2i

Double integer-integer

construction:

l2i = 136

Stack: ..., value-word1, value-word2 => ..., result

value must be a double integer. This takes the lower 32 bits and converts to an integer. The result replaces value on the stack.

l2f

Double integer-single floating point

construction:

l2f = 137

Stack: ..., value-word1, value-word2 => ..., result

value must be a double integer. This is converted to a single floating point number. The result replaces value on the stack.

l2d

Double integer-double floating point

construction:

l2d = 138

Stack: ..., value-word1, value-word2 => ..., result-word1, result-word2

value must be a double integer. This is converted to a double precision floating point number. The result replaces value on the stack.

f2i

Single-precision floating point-integer

construction:

f2i = 139

Stack: ..., value => ..., result

value must be a single floating point number. This is converted to an integer. The result replaces value on the stack.

f2l

Single-precision floating-point-double integer

construction:

f2l = 140

Stack: ..., value => ..., result-word1, result-word2

value must be a single floating point number. This is converted to a double integer. The result replaces value on the stack.

f2d

Single-precision floating-point

construction:

f2d = 141

Stack: ..., value => ..., result-word1, result-word2

value must be a single floating point number. This is converted to a double precision floating point number. The result replaces value on the stack.

d2i

Double precision floating point-integer

construction:

d2i = 142

Stack: ..., value-word1, value-word2 => ..., result

value must be a double-precision floating point number. This is converted to an integer. The result replaces value on the stack.

d2l

Double-precision floating point-double integer

construction:

d2l = 143

Stack: ..., value-word1, value-word2 => ..., result-word1, result-word2

value must be a double-precision floating point number. This is converted to a double integer. The result replaces value on the stack.

d2f

Double precision floating point-Single precision floating point

construction:

2df = 144

Stack: ..., value-word1, value-word2 => ..., result

value must be a double-precision floating point number. This is converted to a single floating point number. If an overflow occurs, the result should be infinity with the same sign as value . The result replaces value on the stack.

int2byte

Integer-signed byte

construction:

int2byte = 157

Stack: ..., value => ..., result

value must be an integer. It is truncated into a signed 8-bit result, and then the sign is extended to an integer. The result replaces value on the stack.

int2char

Integer-char

construction:

int2char = 146

Stack: ..., value => ..., result

value must be an integer. This is truncated to an unsigned 16-bit result, followed by zero extending to an integer. The result replaces value on the stack.

int2short

Short integer

construction:

int2short = 147

Stack: ..., value => ..., result

value must be an integer. It is truncated to a signed 16-bit result, and then the sign is extended to an integer. The result replaces value on the stack.

3.11 Control Transfer Instructions

ifeq

Branch if zero

construction:

ifeg = 153 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is 0, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the ifeq.

ifnull

Branch if null

construction:

ifnull = 198 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be a reference to an object. This is popped from the stack. If value is null, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following ifnull.

iflt

Branch if less than zero

construction:

iflt = 155 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is less than zero, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following iflt.

ifle

Branch if less than or equal to zero

construction:

ifle = 158 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is less than or equal to zero, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following the ifle.

ifne

Branch if nonzero

construction:

ifne = 154 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is nonzero, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following the ifne above.

ifnonnull

Branch if not null

construction:

ifnonnull = 199 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be a reference to the object. This is popped from the stack. If value is not null, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following ifnonnull.

ifgt

Quarter if greater than zero

construction:

ifft = 157 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is greater than zero, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds at the instruction following the ifgt.

ifge

Branch if greater than or equal to 0

construction:

ifge = 156 branchbyte1 branchbyte2

Stack: ..., value => ...

value must be an integer. This is popped from the stack. If value is greater than or equal to 0, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds at the command following the ifge.

if_icmpeq

Quarter if integers are equal

construction:

if_icmpeg = 159 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is equal to value2 , branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmpeq.

if_icmpne

Branch when integers are not equal

construction:

if_icmpne = 160 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is not equal to value2 , branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmpne.

if_icmplt

Branch if integer is less than

construction:

if_icmplt = 161 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is less than value2 , branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmplt.

if_icmpgt

Quarter if integer is greater than

construction:

if_icmpgt = 163 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is greater than value2 , branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmpgt .

if_icmple

Branch if integer is less than or equal to

construction:

if_icmple = 164 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is less than or equal to value2 , branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmple .

if_icmpge

Branch if integer is greater than or equal to

construction:

if_icmpge = 162 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be integers. These are all popped from the stack. If value1 is greater than or equal to value2, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_icmpge .

lcmp

Double integer comparison

construction:

lcmp = 148

Stack: ..., value1-word1, value1-word2, value2-word1, => ..., result

value1 and value2 must be double integers. They are all popped from the stack and compared. If value1 is greater than value2 , integer value 1 is pushed onto the stack. If value1 is equal to value2 , value 0 is pushed onto the stack. If value1 is less than value2 , value -1 is pushed onto the stack.

fcmpl

Single precision floating point comparison (1 on NaN)

construction:

fcmpl = 149

Stack: ..., value1, value2 => ..., result

value1 and value2 must be single-precision floating point numbers. They are all popped from the stack and compared. If value1 is greater than value2 , integer value 1 is pushed onto the stack. If value1 is equal to value2 , value 0 is pushed onto the stack. If value1 is less than value2 , value -1 is pushed onto the stack.

If either value1 or value2 is NaN, value -1 is pushed onto the stack.

fcmpg

Single precision floating point comparison (1 on NaN)

construction:

fcmpg = 150

Stack: ..., value1, value2 => ..., result

value1 and value2 must be single-precision floating point numbers. They are all popped from the stack and compared. If value1 is greater than value2 , integer value 1 is pushed onto the stack. If value1 is equal to value2 , value 0 is pushed onto the stack. If value1 is less than value2 , value -1 is pushed onto the stack.

If either value1 or value2 is NaN, value 1 is pushed onto the stack.

dcmpl

Double-precision floating point comparison (-1 on NaN)

construction:

dcmpl = 151

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result

value1 and value2 must be double-precision floating point numbers. They are all popped from the stack and compared. If value1 is greater than value2 , integer value 1 is pushed onto the stack. If value1 is equal to value2 , value 0 is pushed onto the stack. If value1 is less than value2 , value 1 is pushed onto the stack.

If either value1 or value2 is NaN, value 1 is pushed onto the stack.

dcmpg

Double precision floating point comparison (1 on NaN)

construction:

dcmpg = 152

Stack: ..., value1-word1, value1-word2, value2-word1, value2-word2 => ..., result

value1 and value2 must be double-precision floating point numbers. They are all popped from the stack and compared. If value1 is greater than value2 , integer value 1 is pushed onto the stack. If value1 is equal to value2 , value 0 is pushed onto the stack. If value1 is less than value2 , value -1 is pushed onto the stack.

If either value1 or value2 is NaN, value 1 is pushed onto the stack.

if_acmpeg

Branch if the object references are equal

construction:

if_acmpeg = 165 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be references to objects. These are all popped from the stack. If the referenced object is not the same, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset.

Execution proceeds at that offset from the address of this instruction. Otherwise execution proceeds with the command following the if_acmpeg.

if_acmpne

Branch when object references are not equal

construction:

if_acmpne = 166 branchbyte1 branchbyte2

Stack: ..., value1, value2 => ...

value1 and value2 must be references to objects. These are all popped from the stack. If the referenced object is not the same, branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset.

Execution proceeds at that offset from the address of this instruction. Otherwise, execution proceeds at the command following the command if_acmpne .

goto

Quarter of all occasions

construction:

goto = 167 branchbyte1 branchbyte2

Stack: no change

branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. Execution proceeds at that offset from the address of this instruction.

goto_w

Branch in all cases (wide index)

construction:

goto_w = 200 branchbyte1 branchbyte2 branchbyte3 branchbyte4

Stack: no change

branchbyte1, branchbyte2, branchbyte3 and branchbyte4 are used to construct a signed 32-bit offset.

Execution proceeds at that offset from the address of this instruction.

jsr

Subroutine jump

construction:

jsr = 168 branchbyte1 branchbyte2

Stack: ... => ..., return-address

branchbyte1 and branchbyte2 are used to construct a signed 16-bit offset. The address of the instruction immediately following jsr is pushed onto the stack. Execution proceeds at an offset from the address of this instruction.

jsr_w

Subroutine Jump (Wide Index)

construction:

jsr_w = 201 branchbyte1 branchbyte2 branchbyte3 branchbyte4

Stack: ... => ..., return-address

branchbyte1, branchbyte2, branchbyte3 and branchbyte4 are used to construct a signed 32-bit offset. The address of the instruction immediately following jsr_w is pushed onto the stack. Execution proceeds at an offset from the address of this instruction.

ret

Return from subroutine

construction:

ret = 169 vindex

Stack: no change

The local variable vindex in the current JAVA frame must contain a return address. The contents of the local variable are written to the pc.

Note that jsr pushes the address onto the stack and ret gets it from a local variable. This disharmony is intentional.

ret_w

Return from subroutine (wide index)

construction:

ret_w = 209 vindexbyte1 vindexbyte2

Stack: no change

vindexbyte1 and vindexbyte2 are local variables in the current JAVA frame, assembled into an unsigned 16-bit index. The local variable must contain a return address. The contents of the local variable are written to the pc. See the ret command for more information.

3.12 Function Return

ireturn

Return integer from function

construction:

ireturn = 172

Stack: ..., value1 => ..., [empty]

value must be an integer. The value value is pushed onto the stack of the previous execution environment. Other values on the operand stack are discarded. The interpreter then returns control to his caller.

lreturn

Return double integer from function

construction:

lreturn = 173

Stack: ..., value-word1, value-word2 => ..., [empty]

value must be a double integer. The value value is pushed onto the stack of the previous execution environment. Other values on the operand stack are discarded. The interpreter then returns control to his caller.

freturn

Return single-precision floating point from function

construction:

freturn = 174

Stack: ..., value => ..., [empty]

value must be a single floating point number. The value value is pushed onto the stack of the previous execution environment. Other values on the operand stack are discarded. The interpreter then returns control to his caller.

dreturn

Return double-precision floating point from function

construction:

dreturn = 175

Stack: ..., value-word1, value-word2 => ..., [empty]

value must be a double-precision floating point number. The value value is pushed onto the stack of the previous execution environment. Other values on the operand stack are discarded. The interpreter then returns control to his caller.

areturn

Return object reference from function

construction:

areturn = 176

Stack: ..., value => [empty]

value must be a reference to an object. The value value is pushed onto the stack of the previous execution environment. Other values on the operand stack are discarded. The interpreter then returns control to his caller.

return

Return (invalid) from procedure

construction:

return = 177

Stack: ... => [empty]

All values on the operand stack are discarded. The interpreter then returns control to his caller.

breakpoint

Transfer control to stop and breakpoint handler

construction:

breakpoint = 202

Stack: no change

3.13 Table Jumping

tableswitch

Jump Table Access by Index and Jump

construction:

tableswitch = 170 ... 0-3 byte pad ... default-offset1 default-offset2 default-offset3 default-offset4 low1 low2 low3 low4 high1 high2 high3 high4 ... jump offsets ...

Stack: ..., index => ...

tableswitch is a variable length command. Immediately after the tableswitch opcode, padding is inserted between zero and three zeros so that the next byte starts at an address multiplied by four. The padding is followed by a series of signed 4-byte quantities: default-offset, low, high, and then high-low +1 also sign the 4-bit offset. The high-low + 1 signed 4-byte offset is treated like a 0-based jump table.

index must be an integer. If index is less than low or index is greater than high , a default-offset is added to the address of this command. Otherwise, low is subtracted from index , the index-lowth component of the jump table is extracted, and added to the address of this instruction.

lookupswitch

Jump Table Access by Key Match and Jump

construction:

lookupswitch = 171 ... 0-3 byte pad ... default-offset1 default-offset2 default-offset3 default-offset4 npairsl npairs2 npairs3 npairs4 ... match-offset pairs ...

Stack: ..., key => ...

lookupswitch is a variable length command. Immediately after the lookupswitch opcode, it is inserted between zero and three zeros, such as padding to start the next byte in an address multiplied by four.

Immediately after the padding there are several signed 4-byte positive pairs. The first pair is special. The first clause of the pair is the default offset, and the second clause of the pair brings the number of the next pair. Each successive pair consists of a match and an offset .

The key must be an integer. The integer key on the stack is compared to each of the above matches . If it is equal to one of them, offset is added to the address of this command. If key does not match any of the matches , the default offset is added to the address of this command.

3.14 Manipulation Object Fields

putfield

Set Fields in Objects

construction:

putfield = 181 indexbyte1 indexbyte2

Stack: ..., objectref, value => ...

or

Stack: ..., objectref, value-word1, value-word2 => ...

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool item will be a field reference to the class name and field name. The item is decomposed into a field block pointer having the field width (in bytes) and the field offset (in bytes).

The field at offset from the beginning of the object referenced by objectref will be set to the value of the top of the stack.

This command handles both 32-bit and 64-bit wide fields.

If objectref is null, a NullPointerException is thrown.

If the specified field is a static field, IncompatibleClassChangeError is invoked.

getfield

Patch Fields from Objects

construction:

getfield = 180 indexbyte1 indexbyte2

Stack: ..., objectref => ..., value

or

Stack: ..., objectref => ..., value-word1, value-word2

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool item will be a field reference to the class name and field name. The item is decomposed into a field block pointer having the field width (in bytes) and the field offset (in bytes).

objectref must be a reference to the object. value in from the start of the object referenced by objectref offset replaces objectref on the top of stack.

This command covers both 32-bit and 64-bit wide fields.

If objectref is null, a NullPointerException is thrown.

If the specified field is a static field, IncompatibleClassChangeError is invoked.

putstatic

Static field setting in class

construction:

putstatic = 179 indexbyte1 indexbyte2

Stack: ..., value => ...

or

Stack: ..., value-word1, value-word2 => ...

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool item will be a field reference to the static field of the class. The field will be set to have the highest value of the stack.

This command handles both 32-bit and 64-bit wide fields.

If the specified field is a static field, IncompatibleClassChangeError is invoked.

getstatic

Get static field from class

construction:

getstatic = 178 indexbyte1 indexbyte2

Stack: ..., => ..., value

or

Stack: ..., => ..., value-word1, value-word2

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool item will be a field reference to the static field of the class.

This command handles both 32-bit and 64-bit wide fields.

If the specified field is a static field, an IncompatibleClassChangeError is raised.

3.15 Method Invocation

There are four commands that implement method calls.

An example method call for an object that dispatches based on the runtime (virtual) type of the invokevirtual object. This is JAVA's normal method dispatch.

Invoke an example method of an object to dispatch based on the compile-time (non-virtual) type of the invokenonvirtual object. This is used, for example, when using keywordsuper or superclass names as method modifiers.

invokestatic Invokes the class (static) method of a named class.

invokeinterface A method call implemented by an interface that retrieves a method implemented by a particular runtime object to find the appropriate method.

invokevirtual

Example method call, dispatch based on runtime type

construction:

invokevirtual = 182 indexbyte1 indexbyte2

Stack: ..., objectref, [arg1, [arg2 ...]], ... => ...

The operand stack must contain a reference to the object and a few arguments. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index of the constant pool contains the complete method symbol and class. A pointer to the object's method table is restored from the object reference. Method symbols are retrieved from the method table. Method symbols are provided to exactly match one of the method symbols in the table.

The result of the lookup is an index in the method table of the named class, which is used with the dynamic type of the object to look in the method table of that type, where a pointer to the method block for the matched method is found. Method blocks indicate the type of method (unique, synchronized, and so on) and the number of arguments predicted on the operand stack.

If the method is marked as synchronized, the monitor associated with the objectref is entered.

The objectref and arguments are popped off of the method stack and become the initial values of the new method's local variables. Execution continues with the first command of the new method.

If the object reference of the operand stack is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokenonvirtual

Example method call to dispatch based on compile-time type

construction:

inokenonvirtual = 183 indexbyte1 indexbyte2

Stack: ..., objectref, [arg1, [arg2 ...]], ... => ...

The operand stack must contain a reference to the object and a few arguments. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index of the constant pool contains the complete method symbol. Method symbols are retrieved from the method table. Method symbols are provided to exactly match one of the method symbols in the table.

The lookup result is a method block. Method blocks represent the type of method (unique, synchronized, and so on) and the number of predicted arguments in the operand stack.

If the method is marked as synchronized, the monitor associated with the objectref is entered.

The objectref and arguments are popped off the stack of this method and become the initial values of the local variables of the new method. Execution continues with the first command of the new method.

If the object reference on the operand stack is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokestatic

Class (static) method calls

construction:

invokestatic = 184 indexbyte1 indexbyte2

Stack: ..., [arg1, [arg2 ...]], ... => ...

The operand stack must contain a few arguments. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index of the constant pool contains the complete method symbol and class. Method symbols are retrieved from the method table of the indicated class. Method symbols are provided to exactly match one of the method symbols in the method table of the class.

The lookup result is a method block. Method blocks represent the type of method (unique, synchronized, and so on) and the number of predicted arguments in the operand stack.

If the method is marked as synchronized, the monitor associated with the classification is entered.

The argument is popped from this method stack and made the initial value of the new method's local variable. Execution continues with the first command of the new method.

If a stack overflow is detected during a method call, a StackOverflowError is called.

invokeinterface

Call interface method

construction:

invokeinterface = 185 indexbyte1 indexbyte2 nargs reserved

Stack: ..., objectref, [arg1, [arg2 ...]], ... => ...

The operand stack must contain an object and a reference to the nargs -1 argument. indexbyte1 and indexbyte2 are used to reconstruct the index into the constant pool of the current class. The item at the index of the constant pool contains the complete method symbol. The pointer to the object's method table is restored from the object reference. Method symbols are indexed in method tables. Method symbols are provided to exactly match one of the method symbols in the table.

The index result is a method block. Method blocks indicate the type of method (unique, synchronized, and so on), but unlike invokevirtual and invokenonvirtual , the number of available arguments (nargs) is taken from the bytecode.

If the method is markedsynchronized, the monitor associated with the objectref is entered.

The objectref and arguments are popped off the stack of methods, which is the initial value of the new method's local variables. Execution continues with the first command of the new method.

If the objectref of the operand stack is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is invoked.

3.16 exception handlings

athrow

Startup exception or error

construction:

athrow = 191

Stack: ..., objectref => [undefined]

objectref must be a reference to an object that is a subclass of Throwable invoked. The current JAVA stack frame is searched for the most recent catch close that catches this class or its superclasses. If a matching catch list term is found, pc is set to the address indicated by the catch list term and continues execution.

If no appropriate catch clause is found in the current stack frame, the frame is popped and the object is launched again. If one is found, it contains the location of the code for this exception. pc is reset to that position and execution continues. If no suitable catch is found in the current stack frame, the frame is popped and objectref is invoked again.

If objectref is null, a NullPointerException is invoked instead.

3.17 Miscellaneous Object Operations

new

New object formation

construction:

new = 187 indexbyte1 indexbyte2

Stack: ... => ..., objectref

indexbyte1 and indexbyte2 are used to construct indexes into the constant pool of the current class. The term at that index must be a class name that can be resolved into a class pointer class . Then a new example of the class is formed, and a reference to the object is pushed onto the stack.

checkcast

Determine if object is of specified type

construction:

checkcast = 192 indexbyte1 indexbyte2

Stack: ..., objectref => ..., objectref

indexbyte1 and indexbyte2 are used to construct indexes into the constant pool of the current class. At that index of the constant pool, the string is assumed to be a class name that can be resolved into a class pointer class . objectref must be a reference to an object.

checkcast determines if an objectref can be added to a reference to an object of class class . A null objectref can be applied to any class. Otherwise, the referenced object must be an example of class or one of its superclasses. If an objectref can be added to the class , execution proceeds to the next command and the objectref remains on the stack.

If no objectref can be added to the class , a ClassCastException is invoked.

instanceof

Determine if object is of specified type

construction:

instanceof = 193 indexbyte1 indexbyte2

Stack: ..., objectref => ..., result

indexbyte1 and indexbyte2 are used to construct indexes into the constant pool of the current class. The string at that index of the constant pool is assumed to be a class name that can be resolved into a class pointer class . objectref must be a reference to an object.

instanceof determines if objectref can be added as a reference to an object of class class . This command is objectref an example of a class or one of its superclass overwrite the objectref 1. Otherwise objectref is overwritten with zeros. If objectref is null, it is overwritten by zero.

3.18 Monitors

monitorenter

Entering a Monitored Area of Code

construction:

monitorenter = 194

Stack: ..., objectref => ...

objectref must be a reference to an object.

The interpreter wants to gain exclusive access to the objectref through the lock mechanism. If another thread has already locked the objectref , the handy thread waits until the object is unlocked. If the object is not locked, an exclusive lock is obtained.

If objectref is null, a NullPointerException is invoked instead.

monitorexit

Out of Monitored Areas of Code

construction:

monitorexit = 195

Stack: ..., objectref => ...

objectref must be a reference to an object. The lock on the object was released. If this is the last lock this thread has on that object (one thread is allowed to have multiple locks on a single object), another thread waiting for the object to be available is allowed to proceed.

If objectref is null, a NullPointerException is invoked instead.

Appendix A: Optimization

The following pseudo-instruction sets at the end of _quick are variations of JAVA virtual machine instructions. These are used to improve the speed of interpreting bytecodes. They are not part of the virtual machine specification or instruction set, and are not visible outside of a JAVA virtual machine implementation. However, within the virtual machine implementation, they turned out to be effective optimizations.

The compiler from the JAVA source code to the JAVA virtual machine instruction set only removes non-_quick instructions. If the _quick pseudo-instruction is used, examples of non-_quick with the _quick variant are each overwritten at runtime by its own _quick variant. Subsequent execution of the command example would be a _quick variant.

In all cases, if the command has an alternative with the subscript _quick, the command refers to the constant pool. If _quick optimization is used, each non-_quick command with the _quick variant does the following:

Decompose the specified item in the constant pool;

If an item in the constant pool cannot be resolved for some reason, it will send an error;

It converts itself to the _quick version of the command. The commands putstatic, getstatic, putfield and getfield each have two _quick versions;

Run the scheduled action.

This is the same as the behavior of a command without _quick optimization, except for the additional step in which the command overwrites itself with the _quick variant.

The _quick variant of the instruction assumes that the entries in the constant pool have already been resolved, and that decomposition will not cause any errors. This simply performs the intended action on the disassembled item.

Note: Only a few calling methods support a single byte offset into an object's method table. For calls with more than 256 methods, some calls cannot be made faster with these bytecodes alone.

This appendix does not provide opcode values for pseudo-instructions because they are invisible and change.

A.1 Constant Pool Resolution

When the class is read, an array constant_pool [] of size n constants is formed and assigned to one field of the class. constant_pool [0] is set to a point for a dynamically allocated array indicating which fields of the constant_pool have already been decomposed. constant_pool [1] to constant_pool [nconstants-1] are set to the points of the "type" field corresponding to this constant item.

When a command that references a constant pool is executed, an index is generated and constant_pool [0] is checked to see if the index has already been decomposed. If so, the value of constant_pool [index] is returned. Otherwise, the value of constant_pool [index] is decomposed into an actual pointer or data, overwriting whatever value is present in constant_pool [index].

A.2 Constant Pushing on the Stack (_quick variant)

idcl_quick

Push item from constant pool to stack

construction:

idcl_quick indexbyte1

Stack: ... => ..., item

indexbyte1 is used as an unsigned 8-bit index into the constant pool of the current class. The item at that index is pushed onto the stack.

idc2_quick

Push item from constant pool to stack

construction:

idc2_quick indexbyte1 indexbyte2

Stack: ... => ..., item

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant at that index is decomposed and the item at that index is pushed onto the stack.

idc2w_quick

Push double-precision or double-precision floating point from constant pool to stack

construction:

idc2w_quick indexbyte1 indexbyte2

Stack: ... => ..., constant-word1, constant-word2

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant at that index is pushed onto the stack.

A.3 Array Management (_quick variant)

anewarray_quick

Assign a new reference array to the object

construction:

anewarray_quick indexbyte1 indexbyte2

Stack: ... , size => result

size must be an integer. This represents the number of components in the new array.

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The entry must be a class.

A new array is allocated that can hold the indicated class type and size components, and result is a reference to this new array. An attempt is made to allocate an array large enough to contain a size item of the specified class type. All components of the array are initialized to zero.

If size is less than 0, a NegativeArraySizeException is invoked. If there is not enough memory to allocate the array, OutOfMemoryError is triggered.

multianewarray_quick

New multidimensional array allocation

construction:

multianewarray_quick indexbyte1 indexbyte2 dimensions

Stack: ... , size1, size2, ... sizen => result

Each size must be an integer. Each represents the number of components in the one-dimensional array.

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The entry created must be a class.

dimensions have the following aspects:

It must be an integer ≥1. This represents the number of dimensions formed. This must be the number of dimensions of the array class.

This represents the number of components popped off the stack. All of these must be integers greater than or equal to zero. These are used as dimensions of dimensions.

If any of the stack's size arguments is less than zero, a NegativeArraySizeException is invoked. If there is not enough memory to allocate the array, OutOfMemoryError is triggered.

result is a reference to the new array object.

A.4 Object field manipulation (_quick variant)

putfield_quick

Field settings for the object

construction:

putfield2_quick offset unused

Stack: ... , objectref, value => ...

objectref must be a reference to an object. value must be a value of the appropriate type for the specified field. offset is the offset into the field of the object. value is written to the object at the offset. objectref and value are both popped off the stack.

If objectref is null, a NullPointerException is thrown.

putfield2_quick

Set double-precision or double-precision floating-point field for object

construction:

putfield2_quick offset unused

Stack: ... , objectref, value-word1, value-word2 => ...

objectref must be a reference to an object. value must be a value of the appropriate type for the specified field. offset is the offset into the field of the object. value is written to the object at offset . objectref and value are popped from the stack.

If objectref is null, a NullPointerException is thrown.

getfield_quick

Patch Fields from Objects

construction:

getfield_quick offset unused

Stack: ... , objectref => ..., value

objectref must be a coordinator for the object. The value of the offset to the object referenced by objectref replaces objectref on the stack top.

If objectref is null, a NullPointerException is thrown.

getfield2_quick

Patch Fields from Objects

construction:

getfield2_quick offset unused

Stack: ..., objectref => ..., value-word1, value-word2

objectref must be a coordinator for the object. offset values to the objects referenced by the objectref replaces objectref on the stack top.

If objectref is null, a NullPointerException is thrown.

putstatic_quick

Set static fields for class

construction:

putstatic_quick indexbyte1 indexbyte2

Stack: ..., value => ...

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool entry will be a field reference to the static field of the class. value must be the appropriate type for that field. The field will be set to have the value value .

putstatic2_quick

Set static fields for class

construction:

putstatic2_quick indexbyte1 indexbyte2

Stack: ..., value-word1, value-word2 => ...

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool entry will be a field reference to the static field of the class. The field must be either a single integer or a double precision floating point number. value must be of the appropriate type for that field. The field will be set to have the value value .

getstatic_quick

Get static field from class

construction:

getstatic_quick indexbyte1 indexbyte2

Stack: ..., => ..., value

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool entry will be a field reference to the static field of the class. The value of that field will replace the handle of the stack.

getstatic2_quick

Get static field from class

construction:

getstatic2_quick indexbyte1 indexbyte2

Stack: ..., => ..., value-word1, value-word2

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The constant pool entry will be a field reference to the static field of the class. The field must be a double integer or a double floating point number. The value of that field will replace the handle of the stack.

A.5 Method Invocation (_quick variant)

invokevirtual_quick

Example method call dispatching based on runtime type

construction:

invokevirtual_quick offset nargs

Stack: ..., objectref, [arg1, [arg2 ...]] => ...

The operand stack must contain an objectref , a reference to the object, and a nargs-1 argument. The method block is restored at the offset of the object's method table, as determined by the object's dynamic type. Method blocks indicate the type of method (unique, synchronized, etc.).

If the method is marked as synchronized, the monitor associated with the object is entered.

The base of the local variable array for the new JAVA stack frame is set to the point for the objectref of the stack, and the objectref and the supplied arguments ( arg1, arg2, ... ) make up the first nargs local variable of the new frame. The total number of local variables used by the method is determined, and after enough space is left for the local, the execution environment for the new frame is pushed. The base of the operand stack for this method call is set to the first word after the execution environment. Finally, execution continues with the first command of the matched method.

If objectref is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokevirtualobject_quick

In particular, call the example method of class JAVA.lang.Object on the array.

construction:

invokevirtualobject_quick offset nargs

Stack: ..., objectref, [arg1, [arg2 ...]] => ...

The operand stack must contain an objectref , a reference to the object or array, and the nargs-1 argument. The method block at the offset of the method block of JAVA.lang.Object is restored. Method blocks indicate the type of method (unique, synchronized, etc.).

If the method is marked as synchronized, the monitor associated with the handle is entered.

The base of the local variable array for the new JAVA stack frame is set to the point for the objectref of the stack, and the objectref and the supplied arguments ( arg1, arg2, ... ) make up the first nargs local variable of the new frame. The total number of local variables used by the method is determined, and after enough space is left for the local, the execution environment of the new frame is pushed. The base of the operand stack for this method call is set to the first word after the execution environment. Finally, execution continues with the first command of the matched method.

If objectref is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokenonvirtual_quick

Example method call dispatching based on compile time type

construction:

invokenonvirtual_quick indexbyte1 indexbyte2

Stack: ..., objectref, [arg1, [arg2 ...]] => ...

The operand stack must contain objectref , a reference to the object, and a few arguments. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The entry for that index in the constant pool contains the method slot index and a pointer to the class. The method block at the method slot index of the indicated class is restored. Method blocks indicate the type of method (unique, synchronized, and so on) and the number of arguments ( nargs ) predicted on the operand stack.

If the method is marked as synchronized, the monitor associated with the object is entered.

The base of the local variable array for the new JAVA stack frame is set to the point for the objectref of the stack, and the objectref and the supplied arguments ( arg1, arg2, ... ) make up the first nargs local variable of the new frame. The total number of local variables used by the method is determined, and after enough space is left for the local, the execution environment of the new frame is pushed. The base of the operand stack for this method call is set to the first word after the execution environment. Finally, execution continues with the first command of the matched method.

If objectref is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokestatic_quick

Class (static) method calls

construction:

invokestatic_quick indexbyte1 indexbyte2

Stack: ..., [arg1, [arg2 ...]] => ...

The operand stack must contain a few arguments. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index of the constant pool contains the method slot index and a pointer to the class. The method block at the method slot index of the indicated class is restored. Method blocks indicate the type of method (unique, synchronized, and so on) and the number of arguments ( nargs ) predicted on the operand stack.

If the method is marked as synchronized, the monitor associated with the method's class is entered.

The base of the local variable array for the new JAVA stack frame is set to the point for the first argument in the stack, and the supplied arguments ( arg1, arg2, ... ) make up the first nargs local variable of the new frame. The total number of local variables used by the method is determined, and after enough space is left for the local, the execution environment of the new frame is pushed. The base of the operand stack for this method call is set to the first word after the execution environment. Finally, execution continues with the first command of the matched method.

If the object coordinator of the operand stack is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

invokeinterface_quick

Call interface method

construction:

invokeinterface_quick idbyte1 idbyte2 nargs guess

Stack: ..., objectref, [arg1, [arg2 ...]] => ...

The operand stack must contain an objectref , a reference to the object, and a nargs-1 argument. idbyte1 and idbyte2 are used to construct indices into the constant pool of the current class. The item at that index of the constant pool contains the complete method symbol. A pointer to the object's method table is retrieved from the object handle .

Method symbols are searched in the object's method table. As an easy way, method symbols in slot guess are searched first. If this fails, a full search for the method table is invoked. Method symbols ensure that they exactly match one of the method symbols in the table.

The lookup result is a mass block. The method block indicates the type of the method (natural, synchronized, etc.) but the number of variable arguments nargs is taken from the bytecode.

If the method is marked as synchronized, the monitor associated with the handle is entered.

The base of the array of local variables for the new JAVA stack frame is set to the point of the handle of the stack, and the handle and the supplied arguments ( arg1, arg2, ... ) make up the first nargs local variable of the new frame. The total number of local variables used by the method is determined, and after enough space is left for the local, the execution environment of the new frame is pushed. The base of the operand stack for this method call is set to the first word after the execution environment. Finally, execution continues with the first command of the matched method.

If objectref is null, a NullPointerException is invoked. If a stack overflow is detected during a method call, a StackOverflowError is called.

guess is the final guess. The guess at each time is set to the method offset that was used.

A.6 Various Object Behaviors (_quick Variants)

new_quick

New object formation

construction:

new_quick indexbyte1 indexbyte2

Stack: ... => ..., objectref

indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The item at that index must be a class. Next, a new example for that class is formed, and a reference objectref for that object is pushed onto the stack.

checkcast_quick

Determine if object is of specified type

construction:

checkcst_quick indexbyte1 indexbyte2

Stack: ..., objectref => ..., objectref

objectref must be a reference to an object. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The object at that index of the constant pool would have already been decomposed.

Next, the checkcast determines if an objectref can be added as a reference to an object of class class . A null reference can be added to any class , otherwise a superclass of type objectref is searched for class . Class is determined to be a superclass of objectref type, or if objectref is null, may be added to objectref. If no class can be added, a ClassCastException is invoked.

instanceof_quick

Determine if object is of given type

construction:

instanceof_quick indexbyte1 indexbyte2

Stack: ..., objectref => ..., result

objectref must be a reference to an object. indexbyte1 and indexbyte2 are used to construct the index into the constant pool of the current class. The entry of class class at that index of the constant pool would have already been decomposed.

instance of determines if an objectref can be applied to an object of class class . A null objectref can be applied to any class , otherwise a superclass of type objectref is searched for the class . If class is determined to be a superclass of type objectref , result is 1 (true). Otherwise, result is 0 (false). If handle is null, result is 0 (false).

According to the present invention, a processor capable of processing raw instructions and simultaneously processing computer platform independent instructions is provided. Since the processor of the present invention does not require a software interpreter, the memory space occupied by the conventional software interpreter can be secured, and the processing speed is improved. It also reduces power consumption, making it ideal for portable applications.

1 is a block diagram of one embodiment of a virtual machine hardware processor included in a dual instruction set processor of one embodiment of the present invention,

2 is a processor flow diagram for generating virtual machine instructions used in one embodiment of the present invention;

3 illustrates an instruction pipeline executed in the hardware processor of FIG. 1;

4A illustrates one embodiment of a logical structure of a stack structure when each method frame includes an operand stack, an environment storage area, and a local variable storage area used by the hardware processor of FIG. 1;

4B illustrates an alternative embodiment of the logical organization of the stack structure when each method frame includes an operand stack on the stack and a local variable storage area, and an environment storage area for the method frame is included on a separate execution environment stack;

4C illustrates an alternative embodiment of the execution environment stack and stack management unit for the stack of FIG. 4B;

4D illustrates an embodiment of a local variable look-side cache in the stack management unit of FIG. 1, FIG.

5 illustrates various possible addons for the hardware processor of FIG. 1;

6A is a block diagram of a first dual instruction set processor in accordance with the principles of the invention;

6B is a block diagram of a second dual instruction set processor in accordance with the principles of the present invention;

6C is a block diagram of a third dual instruction set processor in accordance with the principles of the present invention;

7 is an example of a bytecode used to switch or toggle the processor of the present invention to decode and execute other instructions, such as RISC or CISC instructions, and

8 is a block diagram of a computer system using a processor in accordance with the principles of the present invention.

These and other features of the invention will be apparent from the drawings detailed in the detailed description of the invention. The same or similar features are indicated by the same reference numerals in the description and the drawings.

Claims (17)

A dual instruction set processor configured to be communicatively coupled to a network and local memory, the processor comprising: A first computer platform independent instruction decoder for decoding a plurality of first computer platform independent instructions in a first set of instructions received from either the network or the local memory, A second instruction decoder for decoding a plurality of second instructions in a second instruction set different than the first instruction set; An instruction execution unit for executing the plurality of first computer platform independent instructions decoded by the first computer platform independent instruction decoder, and executing the plurality of second instructions decoded by the second instruction decoder, And said first instruction set is a set of computer platform independent instructions. The method of claim 1, The first computer platform independent command decoder decodes a set mode command that is one of the first set of instructions, and passes the command subsequent to the set mode command to the second command decoder in response to the decoding. Processor. The method of claim 1, And each of the instructions in the first instruction set is a virtual machine instruction. The method of claim 3, wherein And the virtual machine instruction comprises an opcode. The method of claim 1, And said network is the Internet. The method of claim 1, And said network is an intranet network. A dual instruction set processor configured to be in communication with a network and local memory and operable in one of two modes, A first computer platform independent instruction decoder for decoding an instruction in the first computer platform independent instruction set and generating a first decoded instruction in response to the decoding; A second instruction decoder for decoding an instruction in a second instruction set and executing a second decoded instruction in response to the decoding; An instruction execution unit for executing the first decoded instruction and the second decoded instruction, In a first mode of operation, the first computer platform independent command decoder and the command execution unit operate on computer platform independent instructions received from the network, And wherein in the second mode of operation, the first instruction decoder, the second instruction decoder and the instruction execution unit operate on instructions received from the local memory. A computer system communicatively coupled with a public carrier network, the computer system comprising: A communication interface unit communicatively coupled with the public carrier network, the communication interface unit receiving a first computer platform independent instruction set; A memory for storing a computer program of a second instruction set collectively different from said first computer platform independent instruction set; A microprocessor connected with the communication interface unit to receive the first computer platform independent instruction set therefrom, the microprocessor connected to the memory to receive the second instruction set therefrom, The microprocessor A first computer platform independent instruction decoder that decodes computer platform independent instructions in the first set and generates a first decoded instruction in response to the decoding; A second instruction decoder that decodes the instructions in the second set and generates a second decoded instruction in response to the decoding; And an instruction execution unit for executing the first decoded instruction and the second decoded instruction. The method of claim 8, The first computer platform independent instruction decoder decodes a set mode instruction that is an instruction in the first instruction set, and activates the second instruction decoder in response to the decoding to decode a second instruction subsequent to the set mode instruction. And a computer system. The method of claim 8, Wherein each instruction in the first computer platform independent instruction set is a virtual machine instruction. The method of claim 10, And the virtual machine instructions include an operation code. The method of claim 8, And said network is an internet network. The method of claim 8, And said network is an intranet. In the dual instruction set processor, A first computer platform independent command decoder capable of decoding a plurality of first computer platform independent instructions, A stack interoperating with the first computer platform independent command decoder, A second command decoder for decoding the plurality of second commands, A flat register cooperating with said second instruction decoder, and And an instruction execution unit for executing the plurality of first computer platform independent instructions and the plurality of second instructions in association with the stack and the flat register. The method of claim 14, The first computer platform independent command decoder is configured to decode a set mode command, which is one of the plurality of first computer platform independent commands, and activates the second command decoder in response to the decoding to continue to the set mode command. And decoding the second instruction. The method of claim 14, And the dual instruction set processor is connected to an internet network. The method of claim 14, And the dual instruction set processor is coupled to an intranet.