Browse Prior Art Database

Method and Mechanism for Dynamic Loader

IP.com Disclosure Number: IPCOM000110494D
Original Publication Date: 1992-Dec-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 6 page(s) / 232K

Publishing Venue

IBM

Related People

Chan, VS: AUTHOR [+3]

Abstract

Breaking large programs up into smaller units has several valuable features. First, only the needed parts have to be loaded into storage. Second, sections of code that are common to many programs can be loaded into commonly addressable storage and used by all users of the system. This saves space, saves loading and system overhead time, and makes servicing programs easier since only one copy of the code needs to be changed when bugs are found.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 32% of the total text.

Method and Mechanism for Dynamic Loader

       Breaking large programs up into smaller units has several
valuable features.  First, only the needed parts have to be loaded
into storage.  Second, sections of code that are common to many
programs can be loaded into commonly addressable storage and used by
all users of the system.  This saves space, saves loading and system
overhead time, and makes servicing programs easier since only one
copy of the code needs to be changed when bugs are found.

      Figure 1 shows a process address space.  In it, there is a
program which was loaded by the operating system.  The program is
self-contained with six functions or procedures, F1 through F6.  Each
of these functions is able to invoke, or call, any of the other
functions, because all six were linked together.

      Figure 2 shows a process address space in which three separate
program entities have been loaded.  F1 is able to call F2 and vice
versa, because those functions were linked together. F1 cannot call
F3, however, because it resides in a separate load module and there
is no means of F1 discovering the address of F3 without F1 having
been coded to find it.  The method described here can be used to
enable any function shown in Figure 2 to call any other function,
without changing the source code logic in any of the existing
functions.

      In reality, functions do not execute by themselves.  There are
support structures required to build the language environment.  A
simplified view of these structures (for a C program) is shown in an
address space in Figure 3.  A context (CTX) consists of
machine-dependent data, such as a program counter.  A stack is used
to support functions calling other functions.  A stack frame is
pushed onto the stack whenever a function calls another function.  A
stack frame may contain the general purpose registers, local or
automatic variables, and so on.  A heap contains storage allocated
that is not local or automatic.  Heap storage persists across
function calls.  Not shown is a typical storage area, similar to the
heap, where global variables, or writable static, is kept.

      Figure 4 is similar to Figure 3, except that it shows several
load modules which make up one logical program having six functions
(but only one copy of a language, or execution, environment to
support the one logical program).

      Figure 5 shows two address spaces, each having a private copy
of a load module containing functions F5 and F6, and a commonly
addressable section of storage containing two load modules with two
functions in each.  The functions F1, F2, F3 and F4 can be called
from either of the two address spaces.  If function F5 is currently
executing, it can call function F6, but it will be a private copy of
F6.  F5 can call function F1, and it will be a public copy of F1.

      Functions F1, F2, F3 and F4 can be located in commonly
addressable storage, as shown in Figure 5...