Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-08-03
2004-02-10
Chavis, John (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S143000, C711S001000
Reexamination Certificate
active
06691307
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer systems. More particularly, the present invention relates interpreter optimization for native endianness.
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.
Optimizing the processing of Java™ bytecodes is complicated by the way in which different computers store data. The “endianness” of a computer CPU is determined by whether the least significant bit is in the lowest or highest addressed byte. In a little-endian computer, the low-order byte of a number is stored in memory at the lowest address, and the high-order byte at the highest address. In a big-endian computer, the high-order byte of a number is stored in memory at the lowest address, and the low-order byte at the highest address. Big-endian order is also known as network order. Table 1 illustrates the different byte ordering used by little-endian and big-endian computers.
TABLE 1
Big-endian
byte 0
byte 1
byte 2
byte 3
Little-endian
byte 3
byte 2
byte 1
byte 0
The different byte ordering means that little-endian and big-endian systems store multibyte quantities differently. For example, the 32-bit (four byte) quantity represented by the hex constant 0×11AABBCC is equivalent to the number 296,401,868. However, Table 2 shows the different ways little-endian and big-endian systems store the value 0×11AABBCC. The most significant (big) byte, 0×11, is stored first on the big-endian system and last on the little-endian system.
TABLE 2
Big-endian
0x11
0xAA
0xBB
0xCC
Base
Base
Base
Base
Address+0
Address+1
Address+2
Address+3
Little-endian
0xCC
0xBB
0xAA
0x11
Base
Base
Base
Base
Address+0
Address+1
Address+2
Address+3
Intel processors and DEC Alphas use little-endian byte order. IBM's 370 computers, most RISC-based computers and Motorola microprocessors use big-endian byte order.
Native and translated programs cannot share binary data without taking into account the big-endian vs. little-endian architectural differences. Otherwise, the same binary data residing on disk or in memory looks different to each type of program. Little-endian systems typically order bytes right to left, so the native program looks to the last byte for the most significant bit. Because a typical big-endian system orders bytes in the reverse direction, the translated program looks to the first byte for the most significant bit. For example, if a big-endian processor writes a file targeted to a little-endian processor, the byte order must be reversed. Similarly, if a little-endian processor reads a file that was targeted for a big-endian processor, the byte order must be reversed before the contents of the file are interpreted.
Furthermore, files containing varying length fields cannot be converted from one byte-ordering convention to another simply by swapping all the bytes. Some examples of files having varying length fields include program binary files and Java™ classfiles. To change byte ordering, programs are typically recompiled using the appropriate compiler option. However, Java™ classfiles must be in big-endian order. In this case, a Java™ interpreter running on a little-endian processor typically organizes code according to native endianness on the fly.
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 interpreter optimization includes receiving multiple data units organized according to a first endian order, reordering the data units according to a second endian order and interpreting the reordered data units. According to one aspect, the data units include at least one opcode having at least one operand, each operand including at least one data unit. According to another aspect, a class loader reorders the code within a classfile from big-endian format to little-endian format.
REFERENCES:
patent: 5367687 (1994-11-01), Tarsy et al.
patent: 5398328 (1995-03-01), Weber et al.
patent: 5423010 (1995-06-01), Mizukami
patent: 5446482 (1995-08-01), Van Aken et al.
patent: 5493675 (1996-02-01), Faiman, Jr. et al.
patent: 5524256 (1996-06-01), Turkowski
patent: 5572713 (1996-11-01), Weber et al.
patent: 5574923 (1996-11-01), Heeb et al.
patent: 5627975 (1997-05-01), Bryant et al.
patent: 5630084 (1997-05-01), Ikumi
patent: 5634013 (1997-05-01), Childers et al.
patent: 5640545 (1997-06-01), Baden et al.
patent: 5721812 (1998-02-01), Mochizuki
patent: 5778233 (1998-07-01), Besaw et al.
patent: 5778406 (1998-07-01), Willard
patent: 5781763 (1998-07-01), Beukema et al.
patent: 5819117 (1998-10-01), Hansen
patent: 5828853 (1998-10-01), Regal
patent: 5828884 (1998-10-01), Lee et al.
patent: 5898896 (1999-04-01), Kaiser et al.
patent: 5905895 (1999-05-01), Halter
patent: 5913064
Chavis John
Schaub John P.
Sun Microsystems Inc.
Thelen Reid & Priest LLP
LandOfFree
Interpreter optimization for native endianness does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Interpreter optimization for native endianness, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interpreter optimization for native endianness will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3352784