Electrical computers and digital processing systems: processing – Instruction decoding – Decoding instruction to accommodate plural instruction...
Reexamination Certificate
1994-10-31
2002-12-17
Ellis, Richard L. (Department: 2653)
Electrical computers and digital processing systems: processing
Instruction decoding
Decoding instruction to accommodate plural instruction...
C712S210000, C711S003000
Reexamination Certificate
active
06496922
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates to a system, implemented in a computer processing unit, for executing instructions that comply with multiple, different instruction set architectures (ISA's), and in particular to a processing unit that statelessly executes such instructions from different ISA's.
A number of multiple-ISA platforms have been proposed which can accommodate different types of instructions by either binary translation or emulation. When binary translation is used, instructions that comply with a given instruction set architecture B (e.g. for x86 processors) can be executed on a second instruction set architecture A (e.g. in compliance with the ISA for SPARC/IEEE Standard 1754 processors) by first being binarily translated into instructions that ISA A understands. They are then executed just as if they were originally written for ISA A.
This approach entails considerable overhead, in that the entire program for ISA B must first be binarily translated before any of it can be run on the ISA-A processor. This not only involves a delay before the user can process the instructions, but ties up the processing of instructions, making the target processor unavailable until the binary translation is complete. Furthermore, the user may need only a small portion of the code being translated at a given time, making it highly inefficient to have to translate the entire code before accessing that portion.
In addition, binary translation involves the copying of the original instructions, which may or may not be allowable by the user's license or by the law of the region where the user is executing the translation. Moreover, the translated instructions must be stored, so that the user is forced to save two copies of the code. If the translated copy is disposed of, then in order to use the code at a later time, it must again be translated to run on the ISA-A processor.
Another approach to executing code written for ISA B on a system using ISA A is emulation, which may be either software emulation or hardware emulation. Software emulation involves inputting instructions that the processor for ISA A would not normally recognize, converting them into equivalent ISA-A instructions, and executing the equivalent instructions in the A processor. This is done by setting the mode of the A processor to emulate ISA B, executing the ISA-B instructions, and then resetting the A processor back to mode A, i.e. for the native ISA.
The mode change is accomplished by a special program that instructs the processor (or the software emulation program) to interpret a succeeding block of data (until resetting of the mode) as ISA-B instructions, e.g. telling a SPARC processor that the forthcoming block of data actually comprises x86 instructions. The SPARC processor then interprets each data word, one by one, as an instruction. When the block of data has been so executed as instructions, the mode-setting program resets the processor mode to the its native (e.g. SPARC) mode.
While ISA-B instructions can successfully be executed this way, it is an inefficient and time-consuming approach, particularly for short sections of code where the overhead of mode changes becomes significant, and does not allow ISA-A and ISA-B instructions to be intermixed in a block of code; that is, the mode of the A processor must be reset every time code for a different ISA is encountered, which involves considerable cycle-time overhead. This is especially so when, during the execution of ISA-B code in processor A, an interrupt is received that requires the execution of a native ISA-A instruction. In this case, the ISA-A instruction must be trapped, interrupting the ISA-B code execution, and system checks whether it is in the correct mode; and since it is not, the mode must be reset to mode A. The trapped instruction is then executed, and the system then resets back to mode B to resume execution of the ISA-B code. This consumes an inordinate number of cycles.
Hardware emulation can run faster than software emulation, using one or more dynamic decode units (which may be an integral part of the native processor, or may be in an add-on module). Conventional hardware emulation, like software emulation, also uses a mode-setting program, so that the processor knows what type of ISA is to be emulated by a given set of instructions, and sends the instructions to the appropriate dynamic decode unit. Though there is a speed-up in execution, the overhead inefficiencies of mode resetting, trapping and interrupting are the same as for software emulation.
Another approach to accommodating multiple instruction set architectures involves incremental compilation, namely the compiling of portions of a program at a time. This has the advantage that an entire program needn't be compiled when only a piece of it is needed, and in a given setting may save considerable compilation time. It has the distinct disadvantage that it does not efficiently handle self-modifying code, since whenever the code is modified it must be recompiled.
In a loop, where the same instructions are executed repeatedly, either software or hard: ware emulation leads to recompiling the same block of code many times over, since the emulation procedure interprets each command anew when it is encountered. Incremental compilation can lead to the same repetition of compiling, when code self-modification occurs. This repetition of compilation is extremely wasteful of processor cycles.
With the continued development of multiple instruction set architectures in the market—such as the SPARC, x86 and PowerPC ISA's and their respective operating systems (Solaris, DOS, MacOS)—it is becoming ever more important that users be capable of executing applications developed for these different instruction set architectures on a single hardware platform, in a manner that does not involve compilation of unneeded blocks of instructions, inefficient multiple compilation of instructions, or the overhead associated with mode setting. Particularly useful would be a system that not only efficiently accommodates multiple instruction set architectures, but can make use of the best of the many programs written for different ISA's by allowing the intermixing of procedures with instructions from different instruction sets.
SUMMARY OF THE INVENTION
The present invention allows the execution of instructions designed for multiple, normally incompatible instruction set architectures in a single new unified architecture. Instructions for a given 32-bit architecture are coupled to an additional 32-bit word containing a predetermined block of bits constituting an ISA tag indicating the native ISA for the “visiting” code, i.e. the 32-bit instruction set architecture for which the code was written. The entire 64-bit instruction stream is received by the “home” processor, which executes each instruction according to its ISA tag.
The home processor thus utilizes a 64-bit instruction set architecture, and in the foregoing manner can execute instructions from any 32-bit architecture, in real time without recompilation or software emulation. In addition to reducing overhead relative to previous methods, this allows for a programmer to freely make use of subroutines, software modules and objects from multiple ISA's in a single application by simply tagging each imported block of code appropriately. The present invention is particularly suited to a VLIW (very long instruction word) architecture, by which a true stateless multi-ISA system is achieved.
REFERENCES:
patent: 3997895 (1976-12-01), Cassonnet et al.
patent: 4415969 (1983-11-01), Bayliss et al.
patent: 4839797 (1989-06-01), Katori et al.
patent: 5115500 (1992-05-01), Larsen
patent: 5313614 (1994-05-01), Goettelmann et al.
patent: 5438668 (1995-08-01), Coon et al.
patent: 5598546 (1997-01-01), Blomgren
patent: 0 150 521 (1985-08-01), None
patent: 0 199 173 (1986-10-01), None
N. Drescher, A New Microarchitecture Based on a Risc Like Structure But With a Cisc Like Instruction Set, Microprocessing and Microprogramming,
Blakely & Sokoloff, Taylor & Zafman
Ellis Richard L.
Patel Gautam R.
Sun Microsystems Inc.
LandOfFree
Method and apparatus for multiplatform stateless instruction... 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 multiplatform stateless instruction..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for multiplatform stateless instruction... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2986307