1. Field of the Invention
This invention relates generally to computer systems and specifically to techniques for linking compiled executable binary program objects for procedure calls.
2. Description of the Related Art
Higher-level program languages provide facilities for making procedure calls, whereby reusable procedures can be compiled in executable form and stored as program objects in a defined location for execution on demand. Such program objects can pass and receive parameters and the results of procedure calls. As used herein, the term procedure in a generic sense means a series of steps, including program segments, functions, subroutines and portions thereof. A program object herein denominates an executable binary code produced by a compiler responsive to a high-level language procedure.
Details of procedure call conventions may differ among various high-level source languages because they are determined by language requirements, operating system conventions and debug requirements. Compatible procedure calls must be made to procedures originally written in the same language or in another language using the same calling or linking protocol. A call to a procedure originally written in a different language may require special steps to ensure that the call is compatible with the original linking or calling protocol. When different linking protocols are used in the original compilations, the necessary restructuring usually requires modification of call procedures at the machine language level.
In many computer systems, including virtually all large and medium size systems, common libraries of procedures are maintained for standard, often-used functions. These procedures are called from application programs, thereby freeing the application programmer from writing and debugging the code required to perform such common functions. Depending on the system design, library functions can be linked to such an application program at link time or they may be dynamically linked at execution time if such activity is supported by the system.
Such large systems are subject to upgrades on a continuing basis and application upgrades or improvements must link to the many pre-compiled program objects already debugged and operating in the system. Cooperating application programs require efficient mechanisms that enable execution control and data to be passed to other procedures. These mechanisms are considerably more complex and less efficient when they must also provide support for the older existing programs that cannot be recompiled to conform to a newer (e.g., more efficient) linking protocol. Accordingly, there is a clearly-felt need in the art for procedural call techniques for introducing improved linking protocols without compromising upward compatibility with existing pre-compiled program objects.
Practitioners in the art have often suggested improvements intended to overcome processing inefficiencies arising from incompatible source languages and linkage protocols. A linkage protocol herein denominates a set of rules, conventions or procedures used by cooperating program objects that facilitates transfer of execution control and data when one program object calls another and when execution control is returned from that call. Normally, linkage protocols are strongly dependent on the hardware and operating system facilities available in the application program operating environment. Linkage protocols vary widely on different hardware and software platforms. Moreover, even on a specific hardware/operating-system platform, several different linkage protocols may be used in different programming languages or different application systems.
For instance, the International Business Machines Corporation (IBM) System/370 hardware platform and the IBM MVS and VM operating systems embrace several linkage protocols. One simple linkage protocol, denominated the "OS Linkage Convention", is widely used. Extensions to and variations of the OS Linkage Convention are employed by applications written in several high-level languages implemented on the System/370 platform. Such variations and extensions are required because the facilities supported by the OS Linkage Convention are insufficient to support all constructs required by newer high-level languages. High-level languages such as COBOL, Fortran, PL/I and C require explicit or implicit specification of several elements making up the linkage between a calling object and a called object. These include the basic system operation elements of (a) a pointer to the entry point of the called object, (b) a pointer to the return location in the calling object, (c) pointers to or values of data items to be passed between the objects, and (d) pointers to or values of descriptive information relating to the data items passed between the objects, such as string length, array size, and the like.
Specification of additional elements unique to a particular high-level language may include such items as (a) identification of the "scope" of the called object in the form of a pointer to the "static data" used thereby, (b) identification of the "global scope" of the overall application program in the form of a pointer to the global information required by the application program environment, and (c) a pointer to a storage area for temporary or local data storage by the called object, often implemented as a "stack". Each of the high-level languages implemented on System/370 and other hardware platforms defines a set of conventions by which such information is passed between cooperating routines written in the same language.
Finally, linkage protocols are often used for a variety of purposes in a variety of circumstances. Although commonly used to support subroutine calls in a high-level language, other linkage protocol uses include (a) calls to a mainline program from the operating system or a subsystem or from another application program, (b) calls to operating system or subsystem services from an application program, and (c) calls between an application program and a library routine providing services intrinsic to the language in which the program is written, such as math routines. In some situations, it is very useful to be able to distinguish in the called routine the circumstances under which it was called, such as where the type of call may require different entry conditions or where initialization is required on certain calls but not on others. A capability in the called routine to distinguish the type of call may be essential for certain processing but may unnecessarily reduce performance efficiency in the usual case not requiring such information. Overall efficiency is compromised where additional logic is inserted in each call to distinguish the call from others for special processing.
It is known in the art that many program objects consist of a single routine and others include many executable routines. In a program object consisting of many routines, one such routine may call another within the same object or a program object may be called from another independent object or from the Operating system or subsystem under which it runs. Each program routine typically provides at least one "entry point" or "name" for access. An entry point herein denominates a spot within the program object at which the processing begins. Some high-level languages such as PL/I permit the user to name multiple entry points within a single program object. Calling, programs then can pass control to a selected entry point in the object to begin the processing peculiar to that entry point.
Most programs written in high-level languages incorporate instructions and information in a compiled program object at each entry point, such instructions being herein denominated a "prologue". These prologues typically provide routine housekeeping such as saving the caller's environment and setting up for execution of the called routine. Prologues may also contain information that identifies the called routine, such as the routine name, language, compile date and the like. This information is commonly used for debugging or problem analysis.
It is known in the art to store a processed version of the source code with the compiled object for retranslation to machine code to accommodate linkage protocol revisions. Also, it is known to provide microcoded prologue and epilogue instructions for execution under single high-level instructions employed by compilers in some systems, where linkage protocol revisions are accommodated by inserting new microcode to support existing objects. However, because the linking conventions implemented by different high-level languages typically differ from one another, making difficult the construction of efficient heterogenous applications in which a routine written in one language with one linking protocol calls a routine written in another language with another linking protocol, the efficient application of a prologue procedure to improve linkage protocol efficiency without sacrificing upward compatibility was until now unknown in the art. These difficulties have motivated practitioners in the an to suggest a variety of methods for facilitating construction of heterogenous applications where a routine written in one high-level language calls routines written in other high-level languages.
For instance, in James A. Brown et al. U.S. Pat. No. 4,736,321, disclose a method for executing external processes and accessing external data from within an interactive language workspace. The workspace task referring to the external processes or data is synchronized and locked until the process is completed or the data retrieved. Brown et al. teach the use of a "third-party" program object for mediating calls between dissimilar protocols, locking the caller and forcing the return data to be acceptable to the caller before completing the call. Unfortunately, their method doesn't consider the optimization of linkage efficiency in a multi-object data processing system.
Similarly, in Richard T. Brandle et al. U.S. Pat. No. 5,146,593, disclose a system software interface that is called by application programs using a standard protocol. All calls to system library routines are made through this interface and, when called, the interface determines the location and original language of a desired library procedure. The interface then sets up parameters and calls the procedure using the calling convention that it expects. The same interface receives results generated by the library procedure and converts them to the convention expected by the calling application, returning the results in the proper format to the calling application. Unfortunately, the technique disclosed by Brandle et al. involves substantial additional execution overhead (application inefficiency), which is a penalty normally expected in the art when absolutely enforcing compatibility among several high-level languages. They neither consider nor suggest methods for enforcing compatibility without compromising processing efficiency.
Great care is required in designing a common linkage convention to ensure that the needs of each language are satisfied and that the overall application performance efficiency is satisfactory, particularly for call-intensive applications. Practitioners in the art have suggested many schemes for enhanced efficiency in call-intensive applications.
For instance, in Kiritkumar Talati et al. U.S. Pat. No. 4,961,133, disclose a method for providing a virtual execution environment on a target computer using a virtual software machine. Their system provides application program portability and consistency across a number of different hardware/operating-system environments by pre-compilation of the application software. Also, in George A. Spix et al. U.S. Pat. No. 5,179,702, disclose an integrated software architecture for highly-parallel multi-processor systems that proposes useful methods for the efficient control of programs in a highly-parallel multi-processor environment through optimized program object linkage techniques.
In Don A. VanDyke et al. U.S. Pat. No. 5,175,856, disclose an integrated hierarchical representation (IHR) of program objects as a common intermediate representation for compiling source code programs written in one or more procedural programming languages into a single executable program object file. Their IHR protocol is language-independent and suitable for sharing by all software system components. Finally, in James Letwin U.S. Pat. Nos. 4,779,187 and 5,027,273, discloses a method and operating system for executing programs in a multi-mode microprocessor that teaches methods for improved operation efficiency in a multi-mode environment based on optimized mode-switching techniques.
Despite the availability in the art of many such cleverly-engineered hardware and operating system features for enhancing program object procedural calling efficiency, improved efficiency is usually obtained at the expense of seamless compatibility with other previously-supported linkage conventions. Thus, improved linkage protocol efficiency does not itself meet the clearly-felt need in the art for a method that implements such improved efficiency without compromising upward compatibility with existing linkage protocols. Such compatibility is prized because existing compiled program objects can then be combined with newly-written or newly-compiled program objects that conform to and require a new (more efficient) linkage convention. The capability to mix and match old and new program objects is highly desirable in large systems having a substantial body of older debugged objects, where the source code for such old routines is not available for re-compile or where the overall application is so complex that complete re-compilation in a single operation is discouraged.
Accordingly, there is a clearly-felt need in the art for a method permitting introduction of a new efficient program object linkage protocol into existing systems without compromising upward compatibility with previously compiled program objects and without compromising the new protocol efficiency. The related problems and deficiencies are clearly felt in the art and are solved by this invention in the manner described below.
USPTO Backgrounds
USPTO Backgrounds