Method and apparatus for the inter-operation of differing...

Data processing: software development – installation – and managem – Software program development tool – Translation of code

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

Reexamination Certificate

active

06199202

ABSTRACT:

TECHNICAL FIELD OF THE INVENTION
This application relates in general to mode switching, and in specific to a mechanism that allows for switching between legacy code, or code compiled for a previous architecture, and native code, or code compiled for the current architecture, and permits the transfer of control back and forth between the two codes in the same program in a transparent manner.
BACKGROUND OF THE INVENTION
Upon changing to a new instruction set architecture (ISA), it is desirable to continue to be able to support legacy code that was compiled on the old architecture. Thus, the problem is that both the legacy code and the new native code that is compiled specifically for the new architecture must be supported on the new ISA The prior art would typically use binary translation to convert the old code into new code. Binary translation is the process of directly translating object code compiled for the legacy instruction set architecture object code for the native architecture. This allows software transition between two dissimilar ISAs.
However, there are situations when a mixture of legacy code and native code needs to be run, and a binary translation itself will not efficiently handle the two sets of code. Thus, a mechanism for mode switching between the two sets of code is required.
One prior art mechanism used switch stubs. The users had to manually create these switch stubs statically or when the program was developed. The stubs would be positioned between the legacy code and the native code, and when the application wanted to make a mode transition or a switch from emulating the old legacy code to executing the new native code, the application would explicitly transfer control via one of these switch stubs. A mode transition is where the flow of execution in the program switches from legacy code to native code, or vice versa. For the remainder of this application the legacy code will be referred to as compatibility mode code or CM, and the native mode code will be referred to a native mode code or NM.
Another prior art mechanism for performing mode switches used a universal procedure pointer (UPP), which are dynamically created. Thus, before the application makes a call to a routine or procedure that is written in CM, the application would explicitly create a universal procedure pointer for that procedure. The application would take the address of the CM code, and pass it to a system routine that would create a UPP pointer for the CM code. In addition to the address, the application would have to pass additional information about the specific routine or procedure, specifically, a parameter profile. The profile defines the kinds of arguments the procedure call is expecting, so that the universal procedure pointer is built to pass it through a dynamically created stub that would automatically reformat the arguments. This mechanism works similarly in each direction, i.e. from CM to NM, and from NM to CM.
Note that this mechanism is not transparent, if a mode switch is required, it is explicitly made, i.e. the user had to know it was going to be done when writing the program. The application would pass the information about the parameter profile to a stub builder, which is similar to a compiler. The stub builder would take the information and generate the switch stubs as assembly code and then those switch stubs would get compiled into the program. The universal procedure pointer which would point to a little stub.
A serious problem with the prior art mechanisms is that they are not transparent. The user must explicitly know about all the transitions that might be made between compatibility mode and native mode, and prepare for them ahead of time, by either building the switch stubs or creating the code that would dynamically create the UPP. Moreover, the user must be concerned about parameters, because the parameter passing conventions are different between the compatibility mode and native mode procedures. Thus, whenever a procedure call is made that requires a mode switch, either from CM to NM or from NM to CM, the application would have to bundle all of the arguments that are to be passed, and reformat them to match the conventions of the procedure being called. Additional information about the procedure that is being called must be maintained in order to build the switch stub or the UPP. The parameter reformatting or marshalling takes place during run time. Consequently, system performance is adversely affected as well.
Therefore, there is a need in the art to have a mechanism that would allow legacy code or CM which is compiled for an old architecture to be linked with native code or NM which is compiled for the new architecture with no additional effort.
SUMMARY OF THE INVENTION
These and other objects, features and technical advantages are achieved by a system and method that allows compatibility mode code and native mode code to be placed in the same program, and permits the program to transfer control freely back and forth between the two modes in a transparent manner. Thus, the programmer does not have to make any explicit preparations to allow mode switching. Moreover, the switching is performed in an efficient manner so that the calls between modes are not substantially penalized with respect to calls made within the same mode.
In order to allow the inter-operation of disparate code in the same application, it is necessary to detect when an execution thread is attempting to cross a mode boundary, e.g. call a procedure that is written in a different mode. The mode switch must be detected in order to facilitate any necessary conversions between run time architectures and the invocation of any necessary instruction emulators.
The inventive mechanism exploits the fact that position independent code typically uses an indirect method for locating the address and global data offset for the called or target procedure. The method indexes into a procedure label table (PLT), which contains the actual address of the function being called, as well as its linkage pointer, which gives the function access to its data. That information is made available to the linker or dynamic loader via a procedure label (p-label) that exists for each procedure visible outside of a load module. The linker and loader are aware of the type of code in each load module. When the linker or loader detects that a mode boundary is being crossed, instead of instantiating the PLT entry with the actual function address, it will insert the address of a mode switch stub in the emulation sub-system. The p-label has been extended to contain a separate segment for each supported run time/architecture. The mode switch stub will perform any necessary actions such as converting parameters, switching stacks, invoking the emulator, etc., to facilitate the switching between CM and NM, and vice versa. Once the mode switch is completed, execution of the program will resume at the called procedure.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.


REFERENCES:
patent: 5805895 (1998-09-01), Breternitz, Jr. et al.
patent: 5828897 (1998-10-01), Kirsch et al.
patent: 5842017 (1998-11-01), Hookway et al.
Chisolm et al. The Use of Computer Language Compilers In Legacy Code Migration. IEEE. pp. 137-145, 1999.
Dietrich et al. Saving a Legacy with Objects. ACM. pp. 77-83, Oct. 1989.
Noffsinger et al. Legacy

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method and apparatus for the inter-operation of differing... 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 the inter-operation of differing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for the inter-operation of differing... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2526731

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.