Opcode numbering for meta-data encoding

Details Opcode numbering for meta-data encoding Opcode numbering for meta-data encoding

1999-06-23

2002-10-08

Pan, Daniel H. (Department: 2183)

Electrical computers and digital processing systems: processing

Instruction decoding

Predecoding of instruction component

C712S209000, C712S211000, C712S227000, C717S118000, C717S159000, C717S166000, C717S148000

Reexamination Certificate

active

06463521

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer systems. More particularly, the present invention relates to opcode numbering for meta-data encoding.
2. Background
A known problem for software developers and computer users is the lack of portability of software across operating system platforms. As a response to this concern, the Java™ programming language was developed at Sun Microsystems as a platform independent, object oriented computer language.
Java™ achieves its operating system independence by being both a compiled and interpreted language. The way in which this independence is achieved is illustrated in FIG.
1
. First, Java™ source code
10
, which consists of Java™ classfiles, is compiled into a generic intermediate format called Java™ bytecode
14
. Java™'s bytecodes consist of a sequence of single byte opcodes, each of which identify a particular operation to be carried out. Additionally, some of the opcodes have parameters. For example, opcode number
21
, iload <varnum>, takes the single-word integer value stored in the local variable, varnum, and pushes it onto a stack.
Next, the bytecodes
14
are interpreted by a Java™ Virtual Machine (JVM)
16
. The JVM executes the bytecodes, either by interpreting them or by compiling them to native machine code and then executing the compiled code. The JVM
16
is a stacked-based implementation of a “virtual” processor that shares many characteristics with physical microprocessors. The bytecodes
14
executed by the JVM
16
are essentially a machine instruction set, and as will be appreciated by those of ordinary skill in the art, are similar to the assembly language of a computing machine. Accordingly, every hardware platform or operating system may have a unique implementation of the JVM
16
, called a Java™ Runtime System, to route the universal bytecode calls to the underlying native system
18
.
Although Java™ provides portability through bytecodes, Java™ programs lag natively compiled programs, written in languages like C/C++, in their execution time. When a user activates a Java program on a Web Page, the user must wait not only for the program to download but also to be interpreted. To improve Java™'s execution time, optimizations can be introduced into the processing of Java™ bytecodes
14
. These optimizations can be implemented in a variety of manners including as Stand-Alone Optimizers (SAOs) or as part of Just-in-Time (JIT) compilers.
A SAO transforms an input classfile containing bytecode
14
into an output classfile containing bytecodes that more efficiently perform the same operations. A JIT transforms an input classfile containing bytecode
14
into an executable program. Prior to the development of JITs, a JVM
16
would step through all the bytecode instructions in a program and mechanically perform the native code calls. With a JIT compiler, however, the JVM
16
first makes a call to the JIT which compiles the instructions into native code that is then run directly on the native operating system
18
. The JIT compiler permits natively complied code to run faster and makes it so that the code only needs to be compiled once. Further, JIT compilers offer a stage at which the executable code can be optimized.
Increasing demands on computers in general create an incentive to optimize the speed and efficiency of program execution. The run time nature of Java™-like systems provides a significant additional incentive for such optimizations. Accordingly, a need exists in the prior art for a method for optimizing program execution.
BRIEF DESCRIPTION OF THE INVENTION
A method for including opcode information in an opcode includes numbering the opcode such that a property of the opcode is represented by at least one bit of the opcode. According to one aspect, the number of data units required to advance to the next opcode is encoded into the opcode value itself. According to another aspect, opcodes are numbered such that opcodes having the same properties have opcode values in the same opcode range.


REFERENCES:
patent: 4802085 (1989-01-01), Levy et al.
patent: 5303362 (1994-04-01), Butts et al.
patent: 5317740 (1994-05-01), Sites
patent: 5355472 (1994-10-01), Lewis
patent: 5402368 (1995-03-01), Yamada et al.
patent: 5408670 (1995-04-01), Davies
patent: 5463746 (1995-10-01), Brodnax et al.
patent: 5636352 (1997-06-01), Bealkowski et al.
patent: 5638524 (1997-06-01), Kiuchi et al.
patent: 5696936 (1997-12-01), Church et al.
patent: 5778233 (1998-07-01), Besaw et al.
patent: 5787431 (1998-07-01), Shaughnessy
patent: 5835712 (1998-11-01), DuFresne
patent: 5838965 (1998-11-01), Kavanagh et al.
patent: 5905895 (1999-05-01), Halter
patent: 5913064 (1999-06-01), Chen
patent: 1 063 585 (2000-12-01), None
Czajkowski, et al., “Jres: A Resource Accounting Interface for Java”, Oct. 1998, Proceedings of the 1998 ACM OOPSLA Conference, Vancouver, BC.

Affiliated with

Also associated with

Rating

Opcode numbering for meta-data encoding does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Opcode numbering for meta-data encoding, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Opcode numbering for meta-data encoding will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3000216