Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2001-11-29
2004-11-16
Kim, Kenneth S. (Department: 2111)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S138000, C717S139000, C717S148000, C703S026000
Reexamination Certificate
active
06820252
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to data processors, and particularly to a data processor including the function incorporated therein to execute non-native codes in addition to codes native to the processor.
2. Description of the Background Art
Processors are designed and fabricated based on certain architectures. In the architecture, the instruction system, instruction format and the like are specified. The hardware is produced so as to execute instructions of such instruction formats efficiently. The program executed in a data processor is generally written in instruction codes of the mounted processor (referred to as “native code”).
However, there is a case where a program written in an instruction code of a processor other than the mounted processor (referred to as “non-native code”) is to be executed. For example, there may be the case where a program for an old processor with an old architecture is to be executed on a new processor with a new architecture when the program for that new processor is not yet fully developed. Another example is the case where a program written in the language such as Java™ bytecode (“Java” is a trademark of Sun Microsystems, Incorporation) for a virtual processor (called “Java virtual machine”) is to be executed in various different types of apparatuses with different processors.
The conventional practice employed as the means for executing non-native code with a processor includes a software interpreter, a software translator and a hardware translator.
The procedure using a software interpreter is implemented by executing a series of processing steps set forth below with software called a software interpreter on the processor.
(1) Read out non-native code from the memory.
(2) Dispatch a relevant non-native code to the processing routine associated with the readout non-native code.
(3) Execute the processing routine associated with the readout non-native code.
(4) Update the program counter of the non-native code.
This software interpreter per se is written in the code native to the mounted processor.
Software is so flexible that it can actually realize any process if the processing speed is not taken into account. Therefore, the software interpreter can be easily realized. However, there is a problem that the execution speed is degraded since the steps of (1), (2) and (4) are also required in addition to the actual process of step (3).
“Translator” implies a device that converts the program of non-native codes into an equivalent program of native codes. A hardware translator performs this conversion in hardware and a software translator performs this conversion with software.
A hardware translator is disclosed in, for example, U.S. Pat. No. 5,875,336. According to the hardware translator, native codes to realize a process of equal contents to respective non-native codes are generated by hardware in order to simulate the operation of respective instructions of the non-native codes. However, the execution speed of the resultant native code of conversion is inevitably degraded by various reasons set forth in the following.
First, in order to read out the non-native code, the translator must simulate, not only the operation result, but also the PC (Program Counter) value of the non-native code or also the flags, if necessary. Therefore, the operation of one non-native code will be converted into a plurality of native codes.
Secondly, even if there are more registers provided in the processor than the expected number of registers provided in the processor based on the non-native code, the excessive registers cannot be utilized. For example, in the case of the translator, the memory operand of the non-native code is still converted into a memory operand in the native code, and is not allocated to the register.
One solution to the problem that the execution speed of the resultant native code after conversion is degraded is proposed in U.S. Pat. No. 5,898,885. It is premised that the non-native code is a stack machine code such as Java bytecode. According to the proposed procedure, a native code is generated so that, when non-native code that pops data from a stack succeeds non-native code that pushes the data on the stack, these non-native codes will be executed together. Accordingly, the number of accesses to the memory is reduced. As a result, the execution speed can be improved. Similar art is proposed in U.S. Pat. No. 6,026,485.
However, this invention has the disadvantage that the procedure cannot be applied unless there is a data popping step right after the data pushing step due to its constitutional limitation.
The above-described problem of speed degradation is also encountered in the conversion by a software translator. However, the software translator differs from the hardware translator in the flexibility of allowing the conversion process to be implemented in a larger program unit (subroutine unit or class unit) instead of the instruction unit. Since unnecessary memory access and the like can be eliminated in the software translator, speed degradation can be suppressed to a certain level. However, the conversion process will become complicated if a native code that has little speed degradation during execution is to be generated and the conversion processing time will be increased.
In order to suppress such overhead of the conversion processing time, a possible consideration is the usage of the procedure to store in the memory the native codes once converted and generated by the software translator. When the same program portion is to be executed again, the conversion process is not carried out but the resultant native codes of conversion that are stored in the memory are used again. The conversion is skipped when the program portion that has been already converted is encountered at the second time and et seq. Therefore, the execution speed is increased compared to the case where conversion was carried out every time.
However, this procedure requires a great capacity of memory in order to store the resultant native codes after the program of the non-native codes has been converted. As a result, another problem that the memory cost is increased will occur.
In order to suppress increase of the memory capacity for the storage of the resultant native codes of conversion, a possible consideration is to set the size of the RAM (Random Access Memory) that is used to store the resultant native codes of conversion constant. According to this procedure, the RAM is used likewise the so-called cache memory. In the present specification, this RAM is called “software cache”.
According to this procedure, the non-native codes are converted into native codes in the subroutine (or method) unit to be additionally stored in the RAM. When this RAM becomes full, the native codes of a subroutine (or method) that has already been executed and has low possibility of being executed thereafter is dismissed from the RAM. The subroutine (or method) formed of new resultant native codes of conversion is stored in that released and available region of the RAM.
By the usage of such a software cache, it is expected that the software translator can have the increase of the memory capacity suppressed to a certain level. However, the number of conversion processes increases in comparison to the case where all the converted instructions are stored in the memory. As a result, the overhead will be increased. If conversion process is simplified to reduce the conversion processing time for example, if each instruction of non-native codes is converted one by one rather than several of them are converted as a group, the execution speed of the resultant native code after conversion will be degraded, as described before.
Thus, the software interpreter has the problem that the execution speed is significantly reduced. It is also difficult to prevent reduction in the execution speed for the hardware translator, though degradation of the execution speed is not as notable as for the software interpreter. There is also the problem th
Sakamoto Mamoru
Yoshida Toyohiko
Kim Kenneth S.
McDermott Will & Emery LLP
Renesas Technology Corp.
LandOfFree
Selective conversion to native code using hardware... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Selective conversion to native code using hardware..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Selective conversion to native code using hardware... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3352837