Examples of prior access authority controls found in different types of prior computer architectures are: store protection, fetch protection (the scope of such protection may differ, such as by providing it over a segment, page, block of real memory, or a virtual address space). Many current microprocessor architectures support one or more virtual address spaces with some type of controls which constrain accesses to the real and virtual storage of a processor. The IBM S/390 architecture has storage key protection over its real storage page frames (which affects access to its virtual pages which map to the page frames), and address space tokens and storage authorization codes over its virtual address spaces. Such access authority controls are currently implemented by hardware and microcode in the prior and current processor systems.
A need currently exists to execute any program on any processor, no matter how different from the processor was the computer architecture under which the program was written. Currently preventing this objective is the fact that access authority controls implemented in the processor hardware and microcode cannot by used by object programs written for a different computer architecture than that of the processor. Generally the current state of the art is that an object program must be designed and written to execute under the architecture of the processor on which it is designed to execute, unless special emulation means is provided on the processor for the architecture of that program.
Two general types of computer architectures are CISC (Complex Instruction Set Computer) and RISC (Reduced Instruction Set Computer), and each of these architecture types contains many disparate architecture features. For example, the IBM S/390 and the Intel 486 are each CISC types of architecture. The S/390 and 486 platforms are very different from each other, and a program designed to execute on S/390 processors will not execute on 486 processors, and visa-versa. (A computer architecture is sometimes called a computer "platform".)
A recent industry trend exists for migrating programs written for CISC architectures to RISC architectures. This indicates a need to find ways to execute CISC programs on RISC processors.
While most architectures are capable of exhibiting the same computational and logical characteristics, their different architectures typically do not support the same types of access authority mechanisms for providing program isolation, regulating access to sensitive data, etc.
Standard application interfaces have evolved using programming languages (i.e. using source code), through which different processors using the different architecture may support a common programming interface to which application programs may be written. The application may be compiled to different object programs which can execute on different processors designed to use the standard application interface under different computer architectures.
The standard application interface is provided by an application enablement environment, which is a program layer between a kernel program in an operating system designed for that architecture and its application programs (applications).
Services provided by the kernel program have mechanisms and parameters determined by a processor architecture, to insure security of data and data integrity when applications written to the common programming interface are being executed. Some examples of application enablement environments are CICS (Customer Information Control System) on S/390 systems, POSIX (Portable Operating System Interface) on Unix systems, and Microsoft Windows on Intel systems.
An application, if written in a commonly-used high level program language, may be ported among all processors supporting the language by recompiling the application program to the desired processor architecture.
An emulation technique called binary translation can sometimes be employed to convert the object code of some architectures to the executable object code of another architecture. Binary translation has only limited adaptability, in that it reproduces computational and logical characteristics, but not storage access authorization mechanisms.
While these standard interfaces are suitable for migrating some applications among processors which support them, a processor architecture itself limits the interface upon which each kernel program must be written. Since the kernel program must provide services to the application enablement environment by making use of the storage authorization policies enforced by mechanisms inherent in a processor architecture, the kernel program for each architecture must be designed and coded specifically for that architecture, and although high level languages may be employed to some degree to simplify the process, porting of the kernel program from one processor to another usually involves significant rework. The more different one architecture is from another, the more extensive the design and implementation effort.
Furthermore, since a kernel program relies on underlying architectural mechanisms to provide services to the application enablement environment, the ability of a kernel program to support a given environment depends on its underlying architecture. In other words, if two processor architectures support similar access authorization mechanisms, they still may require different kernel programs due to subtle architectural differences. The different kernels may then allow the application enablement environment to port programs from one to the other, since the services provided by the kernel program, whose parameters are defined by their processor architectures, will be similar. In the case of two processor architectures which support dissimilar access authorization mechanisms, however, not only are vastly different kernel programs necessary; but also, due to the dissimilarities in the access authorization mechanisms provided, it is likely that the implementation of a given application enablement environment on the two processors will require a different design approach for each processor architecture. If the application enablement environment is designed to utilize some of the specific mechanisms provided in one processor architecture, which have no equivalent in the other processor architecture, it may still be possible to provide the same application interface on both systems, but impossible to provide the same level of security and data integrity in the application enablement environment implementation for both systems.
The differences in many architectures illustrate this point, e.g. one CISC to another CISC, CISC to RISC, RISC to CISC, and one RISC to another RISC. Application interfaces and their underlying application enablement environments designed for access authorization mechanisms typically found in RISC architectures can often be ported between processors having different RISC architectures. They may sometimes be implemented on CISC processor architectures, although this may require a re-design of the application enablement environment to interface the CISC kernel program. Application interfaces and their underlying application enablement environments designed for the more elaborate access authorization mechanisms typically found in CISC architectures must be re-designed when they are implemented on RISC processors. If the target RISC processor is incapable of providing the function of the CISC authorization mechanisms, the resulting implementation will not reach the level of security and data integrity provided on source CISC implementations. The industry trend of migrating applications, written to such application interfaces, from CISC architectures to RISC architectures brings with it the challenge of preserving the level of security and data integrity expected by the users of these applications. In addition, the lack of portability of application enablement environments and kernel programs between such diverse processor architectures makes such migration an expensive venture.
New risks to computer security and its data integrity are often ignored when an application enablement environment is re-designed to the interface provided by the kernel program on another target processor architecture. Applications are then re-compiled to the new interface or emulated via binary translation of the program code. The risks and exposures associated with this method vary from application to application, and in some cases, are quite undesirable. Also, the expense associated with migrating the application enablement environment from one hardware architectural platform to another is substantial.
An even more costly alternative is to re-design an application suite of programs to a different application interface provided by an application enablement environment that already exists for the target processor. It is possible that an application enablement environment designed for simpler access authorization mechanisms provided by a target processor may utilize the simpler mechanisms to attain a level of security and data integrity that approaches that of the source CISC architecture. While this approach may alleviate many of the risks and exposures associated with the first approach, the expense is such that it is misleading to characterize it as a form of migration, since migration implies some level of savings over a first-time development effort, whereas the expense of this approach of re-designing and re-implementing the application suite may be comparable to that of a first-time development effort.
Software emulation is one solution which may provide access authorization mechanisms of a source CISC architecture, while eliminating the need to migrate the applications, the application enablement environment, or the kernel program. In this approach, a software layer is placed between the source kernel program and the target processor architecture which exhibits the authorization characteristics of the source processor architecture. However, since architectural authority mechanisms are typically associated with system state, their effects permeate the operational aspects of the architecture, and are implicitly realized in a large fraction of the operations supported. This means that a straight forward software implementation of such mechanisms will incur a software pathlength penalty each time such an operation is executed. Due to the aggregate effects of such penalties, this method suffers from substantial performance degradation, which is usually prohibitive.
One method for alleviating some of the performance degradation associated with software emulation is to emulate only the computational and logical characteristics of the source processor architecture. This, however, means that the level of security and data integrity is once again compromised (since the access authorization mechanisms are not being emulated), and that the kernel program or application enablement environment must be migrated (since the instructions in the source processor architecture that are utilized by the kernel program are not being emulated). This is essentially the same as the first approach described, employing the binary translation technique to emulate application behavior.
Another method for alleviating performance degradation associated with software emulation is employing hardware emulation instead, or some combination of software and hardware emulation. Typically, the computational and logical characteristics of the source CISC architecture instructions can be expressed by sequences of target RISC architecture instructions (much like vertical microcode), without substantially changing the target hardware. In some instances, if the intent to migrate programs between the architectures is strong, it may justify such hardware changes. However, the implementation of the source access authorization mechanisms in target hardware typically requires substantial hardware changes. The additional hardware development expense associated with this method of implementing CISC on RISC prevents such a hybrid solution from becoming a cost-effective replacement for RISC processors.
USPTO Backgrounds
USPTO Backgrounds