Abstract: Methods and systems for optimizing generation of natively executable code from non-native binary code are disclosed. One method includes receiving a source file including binary code configured for execution according to a non-native instruction set architecture. The method also includes translating one or more code blocks included in the executable binary code to source code, and applying an optimizing algorithm to instructions in the one or more code blocks. The optimizing algorithm is selected to reduce a number of memory address translations performed when translating the source code to native executable binary code, thereby resulting in one or more optimized code blocks. The method further includes compiling the source code to generate an output file comprising natively executable binary code including the one or more optimized code blocks.

Abstract: Methods and systems for optimizing generation of natively executable code from non-native binary code are disclosed. One method includes receiving a source file including binary code configured for execution according to a non-native instruction set architecture. The method also includes translating one or more code blocks included in the executable binary code to source code, and applying an optimizing algorithm to instructions in the one or more code blocks. The optimizing algorithm is selected to reduce a number of memory address translations performed when translating the source code to native executable binary code, thereby resulting in one or more optimized code blocks. The method further includes compiling the source code to generate an output file comprising natively executable binary code including the one or more optimized code blocks.

Abstract: A computing system and method of executing a software program and translation of instructions for an emulated computing environment. The computing system includes a programmable circuit capable of executing native instructions of a first instruction set architecture and incapable of executing non-native instructions of a second instruction set architecture. The emulator operates within an interface layer and translates non-native applications hosted within an emulated operating system for execution. The computing system includes translated memory banks defined at least in part by the emulated operating system and capable of native execution on the programmable circuit, where the emulated operating system is incapable of execution on the programmable circuit.

Abstract: Systems and methods for testing and validation of translated memory banks used in an emulated system are disclosed. One method includes translating one or more banks of non-native instructions into one or more banks of native instructions executable in a computing system having a native instruction set architecture. The one or more banks of non-native instructions define one or more tests of execution of a non-native instruction set architecture. The method also includes loading a memory with instructions and data defined according to the non-native instruction set architecture and addressed by the one or more tests, and triggering, by an emulator, execution of the translated one or more banks of native instructions. The method further includes, upon detection of an error during execution of the translated one or more banks of native instructions, identifying an error in execution of the non-native instruction set architecture by the computing system.

Abstract: Approaches for recovering state data between boot sessions of an emulated operating system (OS). An OS is emulated on a host OS. In response to each memory acquire request from the emulated OS, an interface to the host OS returns a memory area for use by the emulated OS and stores allocation data associated with the memory area. The allocation data includes an address referencing the memory area and a boot sequence number that indicates a boot session of the emulated OS. While booting the second emulated OS to a current boot session, the stored allocation data is retrieved from the interface, and in response to the stored allocation data including a selected boot sequence number, data from the memory area referenced by the address in the allocation data is stored in retentive storage by the second OS.

Abstract: A memory management interface is provided to synchronize the operation of two disparate operating systems (OSes) that are executing on the same data processing platform. In one embodiment, the first operating system is a legacy OS of the type that is generally associated with an enterprise-level data processing system such as a mainframe. In contrast, the second OS is of a type designed to execute on commodity hardware such as personal computers. The first OS communicates with the second OS via a control logic interface to establish its execution environment, and to perform memory management functions. This interface supports a two-phase boot process that ensures that all memory allocated to the first OS can be released if an error occurs that affects operations of the first OS. This prevents the development of memory leaks.