Data processing: structural design – modeling – simulation – and em – Emulation – Of instruction
Reexamination Certificate
1998-02-09
2001-01-09
Teska, Kevin J. (Department: 2763)
Data processing: structural design, modeling, simulation, and em
Emulation
Of instruction
C703S027000, C712S244000
Reexamination Certificate
active
06173248
ABSTRACT:
FIELD OF THE INVENTION
The present invention lies in the field of software emulation and, more specifically, is directed to faithfully handling exceptions in the context of emulating a user program.
BACKGROUND OF THE INVENTION
Software emulation systems use a combination of instruction interpretation and instruction translation to run a program originally written for an old machine architecture on a new architecture. This technology can also be used to emulate a program for one architecture on the same architecture for the purposes of profiling that program.
An instruction emulator maintains an emulated state that models the state of the legacy architecture. During emulation, the emulator modifies the emulated state in the same way that the machine state would have been modified had the program executed on the legacy architecture. “Instruction interpretation” refers to the process of modeling the effects of each instruction on that emulated state. “Instruction translation” refers to a more sophisticated process in which one or more blocks of code from the legacy program are translated into functionally equivalent blocks of code executable on the new platform. Since dynamic translation eliminates the overhead of the interpreter, it is usually an order of magnitude faster than instruction interpretation. In addition, the translator may optimize the translated code so that it runs faster than the raw translated code. Some of these optimizations reorder the instructions in the translated code. However, this reordering must not change the behavior of the emulated program. The significance of this fact to exception delivery will be explained subsequently.
Emulation also is used for program profiling. “Instruction interpretation” examines the effects of each instruction in the legacy program—one instruction at a time—and forms a corresponding instruction executable on the new platform. “Instruction translation” refers to a more sophisticated process in which multiple instructions, i.e. blocks of code, are translated into a functionally equivalent new block of code executable on the new platform. The new block of code hopefully executes more efficiently than would result from simple instruction interpretation. For example, the translated code might take advantage of instructions that were not available on the old platform. However, frequently a combination of both instruction interpretation and instruction translation is employed to emulate a given user program successfully.
In addition to emulating the semantics of the old instruction set, the emulator must deliver exceptions to the emulated process in a manner consistent with the old system. “Exceptions” can be briefly defined as unexpected or unusual conditions that arise during execution. An exception generally arises in the hardware and is communicated to the operating system (“OS”). The OS in some cases “delivers” the exception to the user application as further explained below. Exceptions can be classified as either synchronous or asynchronous. Synchronous exceptions arise as a direct result of executing an instruction. Examples are arithmetic conditions like overflow or divide by 0, privilege or “permission” faults, etc. In general, the instruction has done something or attempts to do something illegal or exceeding available resources. Asynchronous exceptions are those caused by something external to the program. Examples are timer interrupts, communications with other programs (messages), etc. These can arise at any time and thus are “asynchronous” to the executing program.
Typically, when an operating system (“OS”) generates an exception notice or “signal” to an application, the OS places a “sigcontext” on the application's stack. The sigcontext contains a snapshot of the machine state, plus information about interrupted system calls, if any. The machine state is restored according to the sigcontext when the signal handler returns. The signal handler may also modify the machine state contained in the sigcontext, and any such modifications will be propagated to the real machine state by the OS.
One challenge involved in exception emulation is that the emulator itself may receive exceptions as part of its normal operation. The emulator must determine whether it caused the exception and, if it did, handle it internally rather than deliver it to the emulated application. The emulator cannot allow any exceptions to be blocked, since if one of these exceptions were raised while it was blocked, the emulated application would “hang” when the operating system attempted to deliver the exception.
A related problem arises when the system translates the old code into instructions on the new architecture. In order to improve the performance of the translated code, the translator reorders instructions in the translated code. This introduces the possibility of the translator “speculating” a faulting instruction. In other words, the translator might cause an instruction to be executed that would not have been executed in the original program. If the emulator delivers one of these speculative exceptions to the emulated application, we have changed the exception behavior of the original program. The emulator needs to be able to recover from these exceptions, rather than deliver them to the application program. However, the emulator cannot recover if the signal is blocked, since the kernel will hang when trying to deliver the exception.
The need remains, therefore, for improvements in software emulation to address these exception-handling issues. More specifically, the need remains to accurately emulate the exception behavior that a user program would exhibit if it were it running on the legacy platform for which it was originally constructed.
SUMMARY OF THE INVENTION
One aspect of the present invention addresses the problems mentioned above by maintaining a “virtual exception mask” that indicates what the emulated application's exception mask (or “signal mask”) would be if it were running on the “old” architecture. All system calls that would affect the actual (OS) exception mask are intercepted, and their effects are simulated on the virtual mask. A modified system call is made to change the actual mask, while filtering out selected exceptions so that they cannot be blocked.
The invention makes it possible for the emulator to receive an exception that the emulated application had blocked. In this case the virtual mask, but not the actual mask, will block the exception. When this occurs, the emulator marks the exception as “deferred” rather than pending. This means that the exception should be delivered to the emulated application as soon as the virtual mask no longer blocks the exception. The sets of pending and deferred exceptions are recomputed each time the virtual mask is changed. (Pending exception notices are not necessarily delivered immediately. Typically, an emulator periodically checks for pending notices, and delivers them at appropriately “safe” opportunities.)
Thus one aspect of the invention is a method for processing an exception while emulating execution of a user program constructed for execution on a legacy platform. The method includes the steps of: receiving an exception from the operating system; determining whether the received exception was caused by the emulator program or by the user program; and if the exception was caused by the emulator program, handling the exception internally in the emulator program without delivering the exception to the emulated user program. Further, if the exception was caused by the user program, the method calls for identifying the type of exception; determining whether the identified type of exception is currently blocked by the user program; and, if the identified type of exception is not currently blocked by the user program, delivering notification of the exception to the user program. In a presently preferred embodiment, determining whether the identified type of exception is blocked by the user program includes maintaining a virtual exception mask, as noted above, for simu
Hewlett--Packard Company
Phan Thai
Teska Kevin J.
LandOfFree
Method and apparatus for handling masked exceptions in an... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for handling masked exceptions in an..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for handling masked exceptions in an... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2460151