Browse Prior Art Database

Methodology for Coordinating Two Executable Code Modules in the Same System

IP.com Disclosure Number: IPCOM000109179D
Original Publication Date: 1992-Aug-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 2 page(s) / 95K

Publishing Venue

IBM

Related People

Kilmer, DM: AUTHOR [+2]

Abstract

A method for coordinating two separate executable code modules (links) that reside in the same computer system is disclosed. Each link is allowed access to a previously determined set of subroutines that reside in the other link and to a set of data items shared between the two links. These accesses are designed to minimize overhead and to allow most changes to be made to one link without requiring a re-linking of the other link.

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

Methodology for Coordinating Two Executable Code Modules in the Same System

       A method for coordinating two separate executable code
modules (links) that reside in the same computer system is disclosed.
Each link is allowed access to a previously determined set of
subroutines that reside in the other link and to a set of data items
shared between the two links.  These accesses are designed to
minimize overhead and to allow most changes to be made to one link
without requiring a re-linking of the other link.

      All static data, whether or not it is actually shared by both
links, is declared in a separate data-only object module.  This
object module is included in both links and is linked at the same
address for both links.  Thus, the link creation process resolves all
shared data to the same addresses in both links.

      Static data not only includes the data shared among subroutines
from both links but also data shared among any two subroutines and
data local to a single subroutine that retains its value in between
subroutine invocations.  All static data, and not just the shared
data, is included in this object module in order to inform both links
about the existence of this data and that the storage used by this
data is in use.  This inhibits one link from overwriting the static
data of the other link out of ignorance.

      Subroutine sharing is implemented using a list of jump
instructions called a branch table.  For each subroutine contained in
one link that can be called by the other link, there is a branch
table entry in the former link that contains an instruction that
jumps to that subroutine.  The branch table for each link is located
in a separate code-only object module and is linked at an address
that is...