Patent Application
20130132063
The present disclosure relates generally to translation of computing instructions for native execution of software written for a non-native instruction set architecture. In particular, the present disclosure relates to systems and methods for debugging just-in-time translation of instructions in an emulated system.
Many software applications, in particular those that require a large degree of data security and recoverability, are traditionally supported by mainframe data processing systems. Such software applications may include those associated with utility, transportation, finance, government, and military installations and infrastructures. Such applications are generally supported by CMOS based mainframe systems, because mainframes provide a large degree of data redundancy, enhanced data recoverability features, and sophisticated data security features. These mainframes implement proprietary instruction sets and architectures.
As “off-the-shelf” commodity data processing systems have increased in processing power, there has been movement towards using such systems to support industries that historically employed mainframes for their data processing needs. These computer systems may be used to update legacy data, which may include records from any of the aforementioned sensitive types of applications. This scenario presents several challenges.
First, as previously alluded to, the Operating Systems (OS's) that are generally available on commodity-type systems do not include the security and protection mechanisms needed to ensure that legacy data is adequately protected. For instance, when a commodity-type OS such as Windows or Linux experiences a critical fault, the system must generally be entirely rebooted. This involves reinitializing the memory and re-loading software constructs. As a result, in many cases, the operating environment, as well as much or all of the data that was resident in memory at the time of the fault, are lost. The system is therefore incapable of re-starting execution at the point of failure. This is unacceptable in applications that require very long times between system stops.
In addition, commodity OS's such as UNIX and Linux allow operators a large degree of freedom and flexibility to control and manage the system. For instance, a user within an UNIX environment may enter a command from a shell prompt that could delete a large amount of data stored on mass storage devices without the system either intervening or providing a warning message. Such actions may be unintentionally initiated by novice users who are not familiar with the often cryptic command shell and other user interfaces associated with these operating systems. In such situations, it is important to restrict access to the underlying infrastructure to ensure security and reliability.
In some cases, these concerns are addressed by executing a mainframe emulator upon a Linux operating system that is in turn executing upon commodity instruction processors. One example arrangement of such an emulated environment is illustrated in
In operation, the server 10 cannot natively execute instructions of the emulated operating system 26 or applications 28a-x, as they are written using a different instruction set architecture that is incompatible with that provided by the server 10. Accordingly, the emulator 18 fetches one non-native (e.g., mainframe) instruction at a time from emulated main memory (via an interface to the memory management subsystem 22), and translates that instruction to one or more native instructions of the instruction set architecture supported by the server 10. The server 10 then executes the instruction using the native instruction set architecture.
Typically when executing software on a computing system, it is necessary to ensure that the computing system is capable of performing each of the operations required by the software. This is especially the case when mainframe software is executed, because that type of software typically is required to have a higher degree of reliability and less tolerance for downtime. In general three levels of debug and test are necessary to verify that the translation mechanism is working correctly: unit testing, product testing, and system testing. Such testing features typically must be accounted for in a system that executes or emulates a mainframe system, to ensure continued reliability. This is often inconsistent with execution on a commodity system, which is typically not as robust as a mainframe system.
To validate operation of an emulated system such as that shown in
Some efforts have been taken to improve the performance of an emulated system, for example to allow for replacement of such higher-end mainframe systems. Generally, these efforts are focused on reducing the number of cycles required of the commodity instruction processor to perform the tasks required by the emulated mainframe system. For example, in some cases, emulation systems incorporate real time translation engines which perform a one-for-one translation between each instruction in the emulated instruction set architecture (i.e., the mainframe architecture) and the native instruction set architecture (i.e., the instruction set architecture of the commodity device). This approach generally results in slow performance, due to the overhead required by “on the fly” translation. In other cases, a strictly static translation is performed prior to operation. However, even in these newer arrangements, testing would be required to validate operation of such alternative systems.
An arrangement such as the one shown in
For these and other reasons, improvements are desirable.
In accordance with the following disclosure, the above and other issues are addressed by the following:
In a first aspect, a 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.
In a second aspect, a system executable on a computing device having a native instruction set architecture is disclosed. The system includes a testing component and an emulator component. The testing component is capable of managing execution of an emulator through a software debugger, and configured to load one or more transplant files into the emulator component. The transplant files represent instructions and data organized according to a non-native instruction set architecture. The emulator component is configured to load a bank of translated instructions executable on a native instruction set architecture, the bank of translated instructions derived from a corresponding bank of non-native instructions representing one or more tests of the non-native instruction set architecture.
In a third aspect, a computer-implemented method operable on a computing system is disclosed. The computer-implemented method includes translating one or more banks of non-native instructions into a set of source code instructions, the one or more banks of non-native instructions defining one or more self-checking executable tests of execution of instructions defined in a non-native instruction set architecture. The computer-implemented method also includes compiling the set of source code instructions to generate translated one or more banks of native instructions, and loading a memory with one or more transplant files including instructions and data organized according to the non-native instruction set architecture. The one or more transplant files include a representation of memory, a representation of a state of the instruction processor, and a pointer patch table, the representation of memory addressed by the one or more tests. The computer-implemented method further includes triggering, by an emulator, execution of the translated one or more banks of native instructions, and, 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.
Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.
The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, and/or (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a directory system, database, or compiler.
In general the present disclosure relates to methods and systems for debugging a “just-in-time” static translation emulation system. The methods and systems described herein provide for debug and testing of a system that executes a translated native version of instructions originally written in a non-native instruction set for a non-native instruction set architecture. The methods and systems disclosed herein allow a developer or other user associated with an emulator to validate correct translation of non-native instructions into native instructions, such that, although the entire native instruction set may or may not be validated, the instructions and instruction sequences used in place of non-native instructions are validated, as well as proper translation from the non-native instructions into native instructions, in a bank-based arrangement.
I. Just-in-Time Static Translation Systems
Referring now to
In the embodiment shown, the emulation system 100 executes on a server 110. An example server is described in further detail below in conjunction with
In the embodiment shown, the server 110 includes a firmware layer 112, an interface layer 114, and an installation layer 116. The firmware layer 112 and the installation layer 116 are each communicatively connected to the interface layer 114. As with other emulation systems, the firmware layer 112 and installation layer 116 can be used for booting the server 110, as well as starting one or more system services required to interact with hardware present in the server 110. The interface layer 114 generally represents an operating system maintaining the interface between hardware resources of the server 110. The interface layer 114 can be, in certain embodiments, an operating system compiled for execution on a native instruction set architecture, such as a Linux- or Unix-based operating system. In alternative embodiments, other operating systems could be used, such as a Windows operating system provided by Microsoft Corporation of Redmond, Wash.
In the embodiment shown, the interface layer 114 includes an emulator 118, as well as hardware interface systems such as one or more I/O drivers 120, as well as a memory management subsystem 122 and a clock 124. The hardware interface systems 120-124 generally are used by the interface layer 114 for generalized operation, and are made available to an emulated operating system 126 by the emulator 118 hosted within the interface layer 114. Any of a variety of emulated operating systems can be used, such that the emulated operating system is implemented using a non-native instruction set architecture. In one possible embodiment, the emulated operating system is the OS2200 operating system provided by Unisys Corporation of Blue Bell, Pa. Other emulated operating systems could be used as well, but generally refer to operating systems of mainframe systems.
The emulated operating system 126 can host execution or one or more applications 128a-x (in the illustration shown, 3 such applications 28a, 28b, and 28x are shown). The applications 128a-x are generally maintained in a memory managed by the emulated operating system 126 by separating that memory into memory banks. In the context of the present disclosure, these memory banks are also referred to as non-native memory banks, or banks of non-native instructions. This means that the applications 128a-x defined by the instructions maintained in those banks are written for execution on a non-native instruction set architecture not directly executable by the server 110. Although the size of such memory banks may vary based on the emulated operating system used, in a possible embodiment each memory bank has a size of 262 k words. Other memory bank sizes may be used as well.
In contrast to prior art systems, the interface layer 114 as illustrated in this embodiment also includes a linker component 130, an unlinker component 132, and a bank transfer module 134, each of which are interfaced to one or more translated memory banks in a data store 136. The translated memory banks correspond to emulated, non-native memory banks managed by the emulated operating system 126, but are translated into native instructions, which can be directly executed on the server 110 without requiring further instruction-by-instruction translation.
The linker component 130 manages association of one or more of the translated memory banks in the data store 136 to the emulator 118, which selectively directs execution either (1) from a translated memory bank, natively on the server 110, or (2) based on instruction-by-instruction translation from a non-native memory bank defined by the emulated operating system 126, if no translated memory bank exists or is capable of being linked to the emulator 118.
The unlinker 132 disassociates translated memory banks from the emulator 118. For example, in certain embodiments, only a predetermined number of memory banks can be associated at once with the emulator, for example due to physical memory constraints of the server 110. In such circumstances, only a subset of the available translated memory banks in the data store 136 may be linked to the emulator 118 at once. When a maximum number of translated memory banks has been reached but operation of an application has transferred to an unlinked (but translated) memory bank, one of the currently linked memory banks is disassociated from the emulator 118 by the unlinker 132 (e.g., based on being a least recently used translated memory bank, or other analogous scheme). This will allow the linker 130 to associate the relevant unlinked translated memory bank with the emulator 118 for native execution on the server 110.
The bank transfer module 134 transfers memory banks of non-native instructions to the data store 136, where they can be accessed and translated by a translator component. Additional details regarding translation are provided below.
In use, when the emulator 118 fetches an instruction that transfers control from one bank to another a check is made to see if a translated version of that memory bank has been linked to the emulator 118 within the interface layer 114. If the bank has been linked, the emulator 118 will call the bank directly within the interface layer. The bank executes directly on the instruction processor associated with the server 110, and continues to execute within that environment until another bank transfer or an error exception occurs.
In certain embodiments, overall management of memory banks is provided by the emulated operating system 126, such that the emulated operating system defines one or more memory banks of non-native instructions forming an application to be executed; as needed, the emulated operating system can then trigger translation of the non-native instructions in a particular memory bank to native instructions. The emulated operating system 126 can, when the translated memory bank is formed, trigger operation of the linker 130 to link the translated memory bank to the emulator 118, which can direct execution to occur from the native instructions included in that linked, translated memory bank. As such, the loading, linking, and unlinking of memory banks is controlled by the emulated operating system 126. This provides the necessary reliability in that the emulated operating system controls memory bank management, as opposed to allowing translation at a lower level (e.g., by the emulator 118 or interface layer 114.
It is noted that, if a problem occurs during translation of a memory bank or native execution from that memory bank, operation can revert to execution from an emulated memory bank of non-native instructions, using traditional instruction-by-instruction translation. The translated memory bank can then be examined for errors. Furthermore, the emulated operating system 126 can generate hash values associated with each of the translated memory banks, such that a mismatched hash value may indicate an error or tampering with that translated memory bank, and would trigger retranslation of the non-native version of that memory bank.
Additionally, by translating the memory banks to native instructions, those native instructions can be scheduled and executed using the interface layer 114 and instruction set architecture of the server 110. Accordingly, the particular instruction set architecture and organization of the processing units in the server 110 can be utilized, including registers, memory, out-of-order execution techniques, and other efficiencies that would otherwise be unavailable if instruction-by-instruction translation in an emulator were the only mechanism available. However, each of these alternative techniques require debug and validation, for example using the systems and methods disclosed in
Referring now to
In the embodiment shown, each of the processing units 202 is communicatively connected to a memory subsystem 204. The memory subsystem includes an emulator 118, which is configured to translate and execute an emulated image 208. The emulated image 208 can include, for example, a non-native operating system and associated non-native applications managed by the non-native operating system. For example, the emulated image 208 can represent a mainframe operating system, such as the OS2200 operating system from Unisys Corporation of Blue Bell, Pa., as well as one or more applications designed for operation using that operating system and its associated instruction set architecture.
The memory subsystem further includes the emulator 118 described above, as well as a translator component 210 that includes a just-in-time (“JIT”) compiler 212 and a C compiler 214. The translator component 210 is configured to receive an indication from the emulated operating system (during execution of the emulated image 208 within emulator 118) of the existence of a non-native memory bank. The translator component 210 converts the non-native memory bank to a native, or “translated” memory bank. In an example implementation, a JIT compiler 212 in the translator component 210 parses the instructions and data in the non-native memory bank, and translates those non-native instructions to source code. As a second step, a C compiler 214 (or other equivalent compiler), compiles the source code into native instructions, resulting in a translated, native memory bank, translated on an instruction-by-instruction manner. In the embodiment shown, a plurality of translated memory banks 216a-n are shown (illustrated as native “object” banks generated from emulated memory banks within the emulated image 208), following translation by the translator component 210. In example embodiments, the translated memory banks 216a-n are stored in files managed within an interface layer or other native operating environment, while non-native memory banks are managed within the emulated image 208. Other embodiments providing for management of memory structures are possible as well.
In addition to the above-discussed memory structures, the memory subsystem 204 further includes a bank descriptor table (“BDT”) 218 and a link table 220. The bank descriptor table 218 is generated and managed within the emulated operating system, and stores information about available banks for management by the emulated operating system. The link table 220 tracks which of the translated memory banks are linked to an interface layer operating within the interface layer; in other words, the link table manages translated, native memory banks while the bank descriptor table 218 manages the emulated, non-native memory banks included within the emulated image 208. In example embodiments, the bank descriptor table 218 can contain indexed entries to each of the banks managed by an emulated operating system, including information regarding the usage of the bank, its address, and additionally a link bit defining whether the bank has an equivalent translated version that is directly executable on the interface layer. Analogous fields can be included in the link table, such as a link bit, an index, and a timestamp (for tracking the oldest linked memory bank for bank management purposes).
During typical operation, execution of an emulator 118 and associated non-native applications hosted within that emulator are assigned to a particular programmable circuit 202. In the embodiment shown, execution of the emulated image 208 within an emulator is assigned to processing units 202a, while translation performed by the translator component 210 can be offloaded to a different processing unit 202b. In this way, the first processing unit 202a is dedicated to executing the emulated image 208, such that a minimum amount of overhead (i.e., time not dedicated to direct execution of the emulated, mainframe system defined by the emulated image 208) is required.
Additional aspects of execution of pre-translated banks of instructions are discussed in further detail in copending U.S. patent application Ser. No. ______ entitled “Just-In-Time Static Translation System for Emulated Computing Environments”, the disclosure of which is hereby incorporated by reference in its entirety.
II. Testing Infrastructure
Referring now to
The loader component 504 receives the architecture test 502 and prepares it for execution within an emulation environment. In some embodiments, the loader component 504 generates a set of transplant files based on the architecture test. The transplant files define a state of a system's memory, instruction processor, and C-pointer patch table, to replicate a state of a system that would execute the test 502. The state of the system's memory can include, for example, instructions and data stored in a format recognizable to a system affiliated with the architecture test; in embodiments where the architecture test 502 is written in a non-native instruction set architecture the instructions and data could be stored in a format affiliated with that non-native instruction set architecture. The transplant files can be, in some embodiment, stored in a text or ASCII formatted file.
The loader component 504 also passes the architecture test to a first compiler 506, which receives the architecture test 502 and translates the test from its original instruction set architecture (i.e., in the case of emulation, a non-native instruction set architecture), from the non-native instruction set to a source code instruction set (e.g., C/C++ source code). Optionally, the first compiler 506, also referred to as the JIT compiler, can generate source code including one or more inline non-native instructions or remote procedure calls, reserved for later translation. To perform this translation, the first compiler 506 optionally passes through the code of the architecture test 502 two or more times. In general, the first compiler 506 will read in an input bank file containing the desired architecture test 502, and place that file into an array. The lower and upper address limits of that input bank are then computed, and the entire bank is decoded instruction by instruction. This can include multiple passes across the array. A first pass can be used to locate jumps and internal transfers between banks, for example in the case of receiving a jump instruction or local procedure call. These instructions can be converted to a source code labeled instruction relating to a jump condition. Basic, arithmetic instructions can be located in a second pass and implemented as inline instructions, allowing a second compiler 508 to call a translation library 510, which contains correspondences between the non-native instructions (now defined as source code inlines) and native instructions. A jump table (i.e., defining destinations of jump instructions), boundaries of execute tables, and variables can be computed, and then code for each instruction is generated alongside the computed jump table.
In an example embodiment, the following set of instructions may be included in a particular architecture test 502, which, in the example shown, is originally written in a non-native, OS2200 instruction set architecture:
A prelude, containing the corresponding addressing arrangement used in to establish the array, jump table, and eventual source code would be generated and executed, with the corresponding C code generated by the first compiler 506 appearing as follows:
The second compiler 508 receives the translated source code and generates executable code 512 using the native instruction set of the system on which the test is to be executed (e.g., x86, IA64, ARM, etc). The second compiler 508 can call one or more corresponding translations of non-native instructions to native instructions using a translation library 510. Executable code 512 representing the translated, native instruction version of the selected test of the non-native instruction set architecture is output from the second compiler for execution using the JIT emulation arrangement discussed above in connection with
In certain embodiments, the driver 516 can then extract results 518 from a memory managed within the emulator after execution of the test 502, to determine whether the test executed correctly. Example result output can be generated from the self-validating tests, and can include, for example, messages indicating whether an instruction processor was created correctly, whether a memory image was created and loaded correctly, whether and when a test is executed, and when test results are logged. The test results 518 can also be output to a separate file, and can include information such as the files loaded, results of checksum operations, output of statistics regarding memory used, and any errors that may be encountered during execution of the test.
It is recognized that during typical (non-testing) execution of a JIT static translation emulation system 100, execution will be allowed to continue, and will occur using a main executable allowed to continuously run on the computing system upon which the emulator is run. However, and as illustrated in
As illustrated in further detail in
Referring now to
In the example of
The processing system 804 includes one or more processing units. A processing unit is a physical device or article of manufacture comprising one or more integrated circuits that selectively execute software instructions. In various embodiments, the processing system 804 is implemented in various ways. For example, the processing system 804 can be implemented as one or more processing cores. In another example, the processing system 804 can include one or more separate microprocessors. In yet another example embodiment, the processing system 804 can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processing system 804 provides specific functionality by using an ASIC and by executing computer-executable instructions.
The secondary storage device 806 includes one or more computer storage media. The secondary storage device 806 stores data and software instructions not directly accessible by the processing system 804. In other words, the processing system 804 performs an I/O operation to retrieve data and/or software instructions from the secondary storage device 806. In various embodiments, the secondary storage device 806 includes various types of computer storage media. For example, the secondary storage device 806 can include one or more magnetic disks, magnetic tape drives, optical discs, solid state memory devices, and/or other types of computer storage media.
The network interface card 808 enables the computing device 800 to send data to and receive data from a communication network. In different embodiments, the network interface card 808 is implemented in different ways. For example, the network interface card 808 can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., Wi-Fi, WiMax, etc.), or another type of network interface.
The video interface 810 enables the computing device 800 to output video information to the display unit 812. The display unit 812 can be various types of devices for displaying video information, such as a cathode-ray tube display, an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, an LED screen, or a projector. The video interface 810 can communicate with the display unit 812 in various ways, such as via a Universal Serial Bus (USB) connector, a VGA connector, a digital visual interface (DVI) connector, an S-Video connector, a High-Definition Multimedia Interface (HDMI) interface, or a DisplayPort connector.
The external component interface 814 enables the computing device 800 to communicate with external devices. For example, the external component interface 814 can be a USB interface, a FireWire interface, a serial port interface, a parallel port interface, a PS/2 interface, and/or another type of interface that enables the computing device 800 to communicate with external devices. In various embodiments, the external component interface 814 enables the computing device 800 to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers.
The communications medium 816 facilitates communication among the hardware components of the computing device 800. In the example of
The memory 802 stores various types of data and/or software instructions. For instance, in the example of
Although particular features are discussed herein as included within an electronic computing device 800, it is recognized that in certain embodiments not all such components or features may be included within a computing device executing according to the methods and systems of the present disclosure. Furthermore, different types of hardware and/or software systems could be incorporated into such an electronic computing device.
In accordance with the present disclosure, the term computer readable media as used herein may include computer storage media and communication media. As used in this document, a computer storage medium is a device or article of manufacture that stores data and/or computer-executable instructions. Computer storage media may include volatile and nonvolatile, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, DDR4 SDRAM, solid state memory, read-only memory (ROM), electrically-erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data. Generally, computer storage media represents a non-transitory storage location for data and/or computer executable-instructions. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
Referring now to
The method 900 further includes generating instructions and data to be stored in a memory of a computing system having a native instruction set architecture, but in a memory structure configured according to a non-native instruction set architecture (step 906). In example embodiments, generating instructions and data can include generating one or more transplant files from selected code written in a non-native instruction set, for use on a native computing system (e.g., within the emulation systems as discussed herein). The method 900 also includes loading the emulator with the instructions and test conditions generated in step 906 (step 908), for example through use of a driver 516 or other analogous test component.
The method 900 includes execution of a selected bank of instructions called by an emulator (step 910), for example a bank of native instructions that have been pre-translated using first and second compilers in steps 902-904. Execution of the bank of instructions can include, for example, execution of one or more architecture tests, either in real time or within a debugger configured to manage flow control, breakpoints, and step-by-step code execution. During and after execution of the bank, architecture errors can be detected, for example by detecting erroneous data or operation of the bank of instructions (step 912). If architecture errors are detected, a reporting process can generate results indicating the nature of the error and location within the native translated bank where the error occurred (step 914). If no architecture errors are located, the reporting process outputs a report indicating no errors have been detected, and the translation process is considered to be ready for normal operation using JIT static translations of memory banks linked by the emulator (step 916).
It is recognized that, in embodiments of the present disclosure, the functions/acts noted in the blocks may occur out of the order as shown in
Referring now to
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
