Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-10-28
2001-04-17
Hafiz, Tariq R. (Department: 2762)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C703S023000, C712S227000, C714S038110
Reexamination Certificate
active
06219832
ABSTRACT:
TECHNICAL FIELD OF THE INVENTION
This invention pertains in general to code migrating and optimizing compilers and in particular to optimizing dynamically translated code.
BACKGROUND OF THE INVENTION
A “dynamic translator” is computer program that translates an application program from a first to a second format while the application is executing. Typically, the dynamic translator translates a code block into the second format as program flow enters that code block. Then, the dynamic translator executes the translated code block within an emulated computer system. A dynamic translator can be used, for example, to run a SUN SPARC executable file on a PA RISC computer system by translating the application and emulating a SUN SPARC computer system.
When executing the application, the dynamic translator must accurately simulate the entire state and actions of the emulated computer system. Signal handling is one of the most difficult aspects of the computer system to simulate. Normally, if an application were executing and a signal arrived, then the operating system would create a snapshot of the machine state of the application as it existed when the signal arrived. This snapshot contains the values of all registers, the program counter, and the status bits. In short, the snapshot contains all visible CPU state information.
Therefore, if the application is executing under an emulator, the emulator needs to present the same snapshot when a signal arrives. Presenting the snapshot to the application, however, is very difficult. When the signal arrives, the operating system stops the translator and gives the translator a snapshot of the translation system itself, rather than a snapshot of the application. Accordingly, the translation system must create its own snapshot of the emulated computer system and application. Therefore, the translation system needs to track all visible state information for the emulated CPU.
When the translation system is emulating a CPU, however, it is desirable that the emulator not fully model the machine state. Consider, for example, the INTEL X86 architecture. The X86 architecture includes a large number of condition code flags. Each time the CPU executes an ADD instruction, the CPU sets flags indicating, among other things, whether the result was zero, greater than zero, or in parity. Accordingly, if the translation system fully models the CPU, every time it emulates an ADD it also has to materialize the values of the CPU flags. This emulation can be quite expensive in terms of system resources.
Moreover, there are many times when these flags are never used. Consider, for example, when the application executes three ADD instructions in a row. Each ADD instruction does not consume any flags, but instead sets them. If the translator knows that execution cannot stop in between the three ADDS, then there is no point in emulating the flags set by the first and second ADDs. Therefore, there is no need for the translator to materialize CPU flags for points at which execution cannot stop.
However, a LOAD instruction can generate a trap and thereby stop execution. A trap could occur, for example, if the instruction loads from an invalid address or performs a misaligned memory reference. If the instruction sequence is ADD, LOAD, ADD, then there is a possible stop point between the ADD instructions. Therefore, the translator must materialize the CPU flags because the flags might be consumed by a signal handler if the LOAD instruction traps. In sum, to fully implement signal handling, the translator must fully materialize the entire emulated machine state at any point at which execution could stop.
Still, the overwhelming majority of the machine state variables are never consumed. Accordingly, the translator wastes a lot of resources materializing the variables. Additionally, the translator attempts to execute the application as fast as is possible. For this reason, the translations are optimized using techniques such as out-of-order execution. If the instructions are being moved around and executed out of order, then it is sometimes impossible to generate a fully materialized machine state.
Therefore, there is a need in the art for a translator that properly handles signals but does not necessarily fully materialize the machine state.
There is also a need in the art for a translator that properly handles signals but operates quickly and efficiently.
In addition, there is a need in the art for a translator that properly handles signals while allowing code optimizations such as instruction reordering.
SUMMARY OF THE INVENTION
The above needs are met by a method and system of dynamically translating code that uses code annotations to determine whether the dynamic translator must fully materialize machine state. When an application is compiled, the compiler determines the number of formal parameters expected by each of the application's entry points. Then, the compiler stores annotations indicating each entry point's number of formal parameters in the application's executable file.
When the application is dynamically translated, the dynamic translation system (DTS) aggressively translates the application. “Aggressive translation” means that the DTS assumes the application will not stop at any potential stopping point. Therefore, the DTS does not generate instructions for materializing the machine state at those points.
The DTS intercepts all system calls made by the application. If a signal call does not arm an exception handler, then the DTS continues to execute the application in aggressive mode. If, however, the signal call arms an exception handler, then the DTS looks to the annotations to determine the number of formal parameters expected by the handler.
The number of formal parameters is relevant because, when an exception occurs, the machine state is the third formal parameter passed with the exception signal. Therefore, if an exception handler expects two or fewer parameters, then that handler does not use the machine state. Conversely, if a handler expects three or more parameters, then that handler may use the machine state.
Therefore, the DTS determines whether the exception handler has two or fewer formal parameters. If so, then the DTS continues to aggressively translate the application program. If, however, the exception handler has more than two formal parameters, then the DTS switches to conservative translation. This switch is performed by discarding all previously translated code. Then, all subsequent code is translated with instructions for materializing the machine state at all possible stopping points.
A technical advantage of the present invention is that the dynamic translator properly handles signals yet does not introduce unnecessary instructions for materializing the machine state.
Another technical advantage is that code optimizations such as instruction reordering can be used to the fullest possible extent.
Yet another technical advantage is that the translated code is extremely efficient.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.
REFERENCES:
patent: 4951195 (1990-08-01), Fogg et al.
patent: 5133072 (1992-07-01), Buzbee
patent: 5313614 (1994-05-01), Goettelmann et al.
patent: 5732210 (1998-03-01), Buzbee
patent: 5751982 (1998-05-01), Morley
patent: 5764962 (1998-06-01), Buzbee
patent: 5838978 (1998-11-01), B
Dam Tuan Q.
Hafiz Tariq R.
Hewlett--Packard Company
Ngo Tuan V.
LandOfFree
System and method of using annotations to optimize... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method of using annotations to optimize..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method of using annotations to optimize... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2461397