Objectives

The C/C++ subroutine linkage on z/OS cannot be considered state-of-the art with respect to performance. It represents a disproportionate percentage of total execution time, higher yet for C++ than for C due to the many, typically small, functions. Depending on the style of programming, the total prolog/epilog cost may reach a double digit percentage even for C, and thus represents a significant potential for further program optimization.

The objective of XPLINK is to significantly speed up the linkage for C and C++ routines by using a downward-growing stack and by passing parameters in registers. It includes support for reentrant and non-reentrant code, for calls to functions in DLLs, and compatibility with old code.

With XPLINK, the linkage and parameter passing mechanisms for C and C++ are identical. If you link to a C function from a C++ program, you should still specify extern C to avoid name mangling.

The primary objective of XPLINK is to make subroutine calls as fast and efficient as possible by removing all nonessential instructions from the main path.

This is achieved by introducing the following:
  • Stack growth from higher to lower addresses ("negative-" or "downward-growing"):
    • To eliminate overhead in stack frame allocation
    • To eliminate the need to check for inline stack overflow
    • To allow an improved epilog
    • To allow addressability to information (such as parameters) in the caller's stack frame
  • Biasing the stack pointer (by 2048 bytes), so that small functions can save registers in their own stack frame before updating the stack pointer, avoiding address generation interlocks.
  • Reassignment of registers (see XPLINK register conventions) to support more efficient saving and restoring of registers in function prologs and epilogs.
  • Parameter passing in registers and accepting return values in registers.
  • Elimination of Interlanguage Call (ILC) overhead (marking of stack frame) for non-ILC calls.
  • Faster call sequences for inter-module calls.
  • Passing the address of the data area associated with a function, its "environment," to the function on entry.
  • No branching around Language Environment words.
  • Use of relative branching for function calls where possible.
  • Unification of the various (RENT and NORENT, DLL, and NODLL) function pointer implementations, reducing the costs of all operations involving function pointers.

An important additional objective is reducing the module size in memory, which is accomplished by eliminating unused information in function blocks.