Patent Application
20060095898
The present invention relates generally to the processing of object files and, more particularly, to the integrating of multiple object files from heterogeneous architectures.
In a multiprocessor with separate name spaces corresponding to different processors, a program defined in one name space may reference a program defined on another name space. The processors involved may comprise different machine types, with different architectures, different instructions sets, and different forms of object files.
Traditional methods of resolving the references present problems. For example, a linker could misinterpret object code generated by another processor, and handle the code incorrectly. The programmer could hard code a call from a program running on one processor to a program in the name space of another processor, but the process could become cumbersome. With the hard coding, it would not be possible for runtime reference to the object code, for dynamic linking and object sharing, or for execution time handling of an object from the combined multiprocessor name space.
Therefore, there is a need for a method of integrating multiple object files from heterogeneous architectures so that system tools such as the linker and loader can properly handle the object files, and so that runtime reference to the object files, dynamic linking and object sharing, and execution time handling of objects from the combined multiprocessor name space are possible.
The present invention is a method for integrating multiple object codes from heterogeneous architectures. For a program on a first processor to reference a program from the name space of a second processor, the object code for the second-processor program is enclosed in a wrapper to create object code in the first-processor name space. The header of the wrapped object code defines a new symbol in the name space of the first processor, and the symbol points to the second-processor object code contained in the wrapped object code. Instead of directly referencing the second-processor object code, the referencing program on the first processor references the wrapped object code.
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail.
It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or some combination thereof. In a preferred embodiment, however, the functions are performed by a processor such as a computer or an electronic data processor in accordance with code such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise.
The SPU 110 does not have access to the system memory 108 through load and store instructions. A second DMA controller 114 transfers data from the system memory 108 to local store 112, and the SPU 110 can load and store from there. The DMA controller 114 is connected to the system memory 108 via system bus 116.
In other embodiments of the invention, the architecture of the multiprocessor 100 is different. In an embodiment of the invention, the multiprocessor 100 comprises multiple copies of the PU 102, all sharing a single system memory. In an embodiment of the invention, the multiple copies of the PU 102 each share a single cache. In another embodiment, some groups of one or more PUs share a cache, while some PUs do not have access to a cache. In an embodiment of the invention, there are multiple copies of the SPUs. In an embodiment of the invention, the SPU 110 has its own separate memory.
The wrapping process makes possible the integration of multiple object files from heterogeneous architectures. The wrapping of an SPU 110 object creates a PU 102 object which can be treated for linking and loading purposes as any other PU 102 object. During execution, the SPU 110 object that was wrapped is handled correctly. As a result, the wrapping process makes possible the integration of PU 102 and SPU 110 objects.
For example, to resolve a reference to the SPU 110 object BAR-SPU, the linker links to the PU 102 object BAR-SPU-PU.o. This method supports static and dynamic linking and the object sharing of an SPU 110 object. Similarly, the wrapping allows the loading of any SPU 110 file format. The wrapped PU object 208 is loaded. Further, PU 102 runtime reference can be made to an SPU 110 object. The runtime reference on the PU 102 is to the PU 102 object BAR-SPU-PU.
The wrapping also allows a clear separation of PU 102 object name space and SPU 110 object name space. Code running on the PU 102 does not have to refer directly to an SPU 110 object. Instead, the SPU 110 object is wrapped, creating a PU 102 object, and the PU 102 code refers to the wrapped object, a PU 102 object. The result is also a simple symbol association for PU 102 program reference. PU 102 code refers to a PU 102 symbol, which points to an SPU 110 object. The result gives the capability of pre-linking and mixing both PU 102 and SPU 110 objects. Finally, the wrapping process is friendly to library packaging for both static and dynamic needs.
Having thus described the present invention by reference to certain of its preferred embodiments, it is noted that the embodiments disclosed are illustrative rather than limiting in nature and that a wide range of variations, modifications, changes, and substitutions are contemplated in the foregoing disclosure and, in some instances, some features of the present invention may be employed without a corresponding use of the other features. Many such variations and modifications may be considered desirable by those skilled in the art based upon a review of the foregoing description of preferred embodiments. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.
