Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
2000-02-11
2002-12-31
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C717S152000, C717S152000, C717S152000
Reexamination Certificate
active
06502237
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates generally to computer systems and more particularly to execution of computer programs on non-native computer system architectures.
As is known in the art, computer systems which generally include a central processing unit, a main memory, and input-output device interconnected by a system bus are used to execute computer programs to perform some useful task. One type of computer program is an operating system which is used to interface the central processing unit to an application program. The aforementioned application program is a program used by a user of the computer system to perform the useful task. The operating system includes all of the software resources needed by the computer system to interface each of the hardware elements to the computer system as well as to interface the application program and other programs on the computer system.
The application program which can include programs such as spreadsheets, wordprocessors, electronic mail executes on the computer system under the control of the operating system. In addition, the operating system often includes routines or libraries which the application program uses during execution.
It is generally known that application programs are written for a particular computer architecture that is, computer instruction set, as well as a particular operating system. Computer architectures are varied, but common architectures include the so-called Alpha® architecture by Digital Equipment Corporation's assignee of the present invention, the so called X86 architecture which is based upon the family of microprocessors designed and built by Intel Corp., as well as others such as the Power PC® architecture designed and built by Motorola, IBM and Apple. Other architectures include the VAX® architecture by Digital Equipment Corporation and the PARISC® architecture by Hewlett Packard.
Generally, programs written for one architecture are also written for a particular operating system which is supported on the architecture. Thus, for the aforementioned Alpha architecture, the Alpha architecture supports the Windows NT® operating system by Microsoft Corporation, the Open VMS® operating system, by Digital Equipment Corporation, and the OSF-UNIX operating system by Digital Equipment Corporation.
These application programs written for one architecture and a particular operating system can not directly execute on a different architecture and/or different operating system. In general a so-called source file (which is a non-executable listing of the program) is fed to a compiler and linker to convert the source listings into executable code which a computer can execute.
New computer architectures are developed in order to provide significant performance improvements for the hardware associated with the architecture. For example, the so-called Alpha® architecture based upon the 64 bit Alpha microprocessor in a RISC type architecture (Reduced Instruction Set Computer). On such an architecture, an application program executes much faster with higher performance and thus provides to a user significant performance advantages.
One drawback to a new architecture, however, is that often application programs written for older architectures can not run directly on the new architecture. This occurs because the instruction acts of the new architecture and the old architecture are different and since different instructions are used in each architecture, the programs are not directly transferable.
While it is desirable for a user to migrate to a new higher performance architecture, one of the most significant drawbacks for a user to migrate to a new architecture is the user's pre-existing investment in software applications as well as data files resulting from application programs on the old architecture. That is, an architecture which has been in existence for a number of years and used by a large number of users will represent a substantial cumulative financial investment. If that investment is not transferable to a new architecture users will be highly reluctant to migrate to the new architecture.
There are several approaches which have been developed over the years to assist users to migrate from an old architecture to a new architecture. One approach is the so-called “porting approach”. With the porting approach a software vendor agrees with the owner of the architecture to take its source code (i.e. the non-executable listing) for a particular application program and run the source code through a compiler developed for the new architecture and to perform some sort of checking such as a quality assurance check at the end of the compilation.
Thus, with porting the source code of application is converted into an executable image which can run on the new architecture. Porting is a viable solution for many applications. In particular applications involved in the so-called enterprise computing field are excellent candidates for porting since the nature of the program and the nature of the customer are such that there is an expectation of a high level of support from the software vendor as well as from the owner of the architecture.
However, porting is not always a viable option for certain segments of the computer market. In particular, in the so-called shrinkwrap software market porting is not a viable option. In the shrinkwrap market computer programs are bought relatively inexpensively and are used in personal computers. Often in this market there is not sufficient support for the user.
A further problem with porting is that a relatively large amount of time is required to port an application program to a new architecture, and it requires positive, active intervention of a human in order to port the application program. Further, the concept of porting assures the existence of availability of source code which is not always the case.
Another technique commonly employed is so-called “on-line interpretation”. In on-line interpretation, a software module called an “interpreter” interprets instructions from an executable version of the application program written in the non-native instruction set and chooses instructions or routines to execute in the new architecture. The interpreter is an emulator which responsive to a executable file corresponding to the old architecture provides a converted executable file that is executed on the new architecture.
The interpreter for each instruction tests the instruction to determine the resources needed by the instruction and analyzes the instruction to determine the function of the instruction. From this testing the interpreter maps the instruction to a routine that performs the same function only written in instructions executable on the new architecture. After the routine is identified the routine is executed in the computer system to provide the equivalent function called for in the application program written in the non-native instruction set. After execution a new instruction in the non-native architecture is provided to the interpreter.
Although interpreters are useful to convert application programs between architectures at run time, one of the significant drawbacks of interpreters is that they are exceedingly slow. Thus, performance advantages of the faster, high-performance architectures are lost with using an interpreter to convert instructions from an old architecture to a new architecture.
On-line translators have been used to alleviate this problem somewhat. In an on-line translator, small amounts of code that appears to the run-time system to be repetitive, is translated to improve the efficiency of the interpretation process. Generally a small buffer of the translated code is maintained and is used to execute until it is determined to translated code which has a higher usage rate. In that case the old translated code is overwritten. There are several problems with this approach. One problem is that there are very limited opportunities for optimization since the translation process can not hold up the interpretation process. A second problem is
Hookway Raymond J.
Tye Steven Tony
Yates John S.
Compaq Information Technologies Group L.P.
Das Chameli C.
Hamilton Brook Smith & Reynolds P.C.
Morse Gregory
LandOfFree
Method and apparatus for performing binary translation... 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 performing binary translation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for performing binary translation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2918943