Function calling sequence

This section discusses the standard function calling sequence, including stack frame layout, register usage, and parameter passing.

Registers

The ABI makes the assumption that the processor has 16 general purpose registers and 16 IEEE floating point registers. zSeries processors have these registers; each register is 64 bits wide. The use of the registers is described in the table below.

Table 8.

Register name

Usage

Call effect

r0,

r1

General purpose

Volatile¹

r2

Parameter passing and return values

Volatile

r3, r4,

r5

Parameter passing

Volatile

r6

Parameter passing

Saved²

r7 -

r11

Local variables

Saved

r12

Local variable, commonly used as GOT pointer

Saved

r13

Local variable, commonly used as Literal Pool pointer

Saved

r14

Return address

Volatile

r15

Stack pointer

Saved

f0, f2, f4,

f6

Parameter passing and return values

Volatile

f1, f3, f5,

f7

General purpose

Volatile

f8 –

f15

General purpose

Saved

Access registers 0, 1

Reserved for system use

Volatile

Access registers 2-15

General purpose

Volatile

¹Volatile: These registers are not preserved across function calls.

²Saved: These registers belong to the calling function. A called function shall save these registers' values before it changes them, restoring their values before it returns.

The following registers have assigned roles in the standard calling sequence:

Table 9.

r12

Global Offset Table pointer. If a position-independent module uses cross-linking the compiler must point r12 to the GOT as described in the Section called Dynamic Linking in the chapter called Program loading and dynamic linking. If not this register may be used locally.

r13

Commonly used as the Literal Pool pointer. If the Literal Pool is not required this register may be used locally.

r14

This register will contain the address to which a called function will normally return. r14 is volatile across function calls.

r15

The stack pointer (stored in r15) will maintain an 8-byte alignment. It will always point to the lowest allocated valid stack frame, and will grow towards low addresses. The contents of the word addressed by this register may point to the previously allocated stack frame. If required it can be decremented by the called function – see the Section called Dynamic stack space allocation.

Signals can interrupt processes. Functions called during signal handling have no unusual restrictions on their use of registers. Moreover, if a signal handling function returns, the process will resume its original execution path with all registers restored to their original values. Thus programs and compilers may freely use all registers listed above, except those reserved for system use, without the danger of signal handlers inadvertently changing their values.

Register usage

With these calling conventions the following usage of the registers for inline assemblies is recommended:

  • General registers r0 and r1 should be used internally whenever possible

  • General registers r2 to r5 should be second choice

  • General registers r12 to r15 should only be used for their standard function.

The stack frame

A function will be passed a frame on the runtime stack by the function which called it, and may allocate a new stack frame. A new stack frame is required if the called function will in turn call further functions (which must be passed the address of the new frame). This stack grows downwards from high addresses. Figure 16 shows the stack frame organization. SP in the figure denotes the stack pointer (general purpose register r15) passed to the called function on entry. Maintenance of the back chain pointers is not a requirement of the ABI, but the storage area for these pointers must be allocated whether used or not.

Figure 16. Standard stack frame

The format of the register save area created by the gcc compiler is:

Figure 17. Register save area

The following requirements apply to the stack frame:

The stack space for the register save area and back chain must be allocated by the caller. The size of these is 160 bytes.

Except for the stack frame header and any padding necessary to make the entire frame a multiple of 8 bytes in length, a function need not allocate space for the areas that it does not use. If a function does not call any other functions and does not require any of the other parts of the stack frame, it need not establish a stack frame. Any padding of the frame as a whole shall be within the local variable area; the parameter list area shall immediately follow the stack frame header, and the register save areas shall contain no padding.

Parameter passing

Arguments to called functions are passed in registers. Since all computations must be performed in registers, memory traffic can be eliminated if the caller can compute arguments into registers and pass them in the same registers to the called function, where the called function can then use these arguments for further computation in the same registers. The number of registers implemented in a processor architecture naturally limits the number of arguments that can be passed in this manner.

For Linux for zSeries, the following applies:

If there are more than five integral values or four floating point values, the rest of the arguments are passed on the stack 160 bytes above the initial stack pointer.

Beside these general rules the following rules apply:

Figure 18. Parameter list area

The following algorithm specifies where argument data is passed for the C language. For this purpose, consider the arguments as ordered from left (first argument) to right, although the order of evaluation of the arguments is unspecified. In this algorithm fr contains the number of the next available floating-point register, gr contains the number of the next available general purpose register, and starg is the address of the next available stack argument word.

INITIALIZE

Set fr=0, gr=2, and starg to the address of parameter word 1.

SCAN

If there are no more arguments, terminate. Otherwise, select one of the following depending on the type of the next argument:

DOUBLE_OR_FLOAT:

A DOUBLE_OR_FLOAT is one of the following:

  • A single length floating point type,

  • A double length floating point type.

  • A structure equivalent to a floating point type.

If fr>6, that is, if there are no more available floating-point registers, go to OTHER. Otherwise, load the argument value into floating-point register fr, set fr to fr+2, and go to SCAN.

SIMPLE_ARG

A SIMPLE_ARG is one of the following:

  • One of the simple integer types no more than 64 bits wide (char, short, int, long, long long, enum).

  • A pointer to an object of any type.

  • A struct or a union of 1, 2, 4 or 8 bytes which is not a structure equivalent to a floating point type.

  • A struct or union of another size, or a long double, any of which shall be passed as a pointer to the object, or to a copy of the object where necessary to enforce call-by-value semantics. Only if the caller can ascertain that the object is "constant" can it pass a pointer to the object itself.

If gr>6, go to OTHER. Otherwise load the argument value into general register gr, set gr to gr+1, and go to SCAN. Values shorter than 64 bits are sign- or zero-extended (as appropriate) to 64 bits.

OTHER

Arguments not otherwise handled above are passed in the parameter words of the caller's stack frame. SIMPLE_ARGs, as defined above, are considered to have size of 8 bytes, where simple integer types shorter than 8 bytes are signed or zero-extended (as appropriate) to 8 bytes, and other arguments of size less than 8 bytes will be placed right-justified into a 8 byte slot. float and double arguments are considered to have a size of 8 bytes, where float arguments will be placed right-justified into an 8 byte slot.

The contents of registers and words which are skipped by the above algorithm for alignment purposes (padding) are undefined.

As an example, assume the declarations and the function call shown in Figure 19. The corresponding register allocation and storage would be as shown in Table 10.

int i, j, k, l;

long long ll;

double f, g, h;

int m;



x = func(i, j, g, k, l, ll, f, h,

m);

Figure 19. Parameter passing example

Table 10. Parameter passing example: Register allocation

General purpose registers

Floating-point registers

Stack frame offset

r2: i

f0: g

160: m

r3: j

f2: f

r4: k

f4: h

r5: l

r6: ll

Variable argument lists

Some otherwise portable C programs depend on the argument passing scheme, implicitly assuming that 1) all arguments are passed on the stack, and 2) arguments appear in increasing order on the stack. Programs that make these assumptions have never been portable, but they have worked on many implementations. However, they do not work on z/Architecture because some arguments are passed in registers. Portable C programs use the header files <stdarg.h> or <varargs.h> to deal with variable argument lists on zSeries and other machines as well.

Return values

In general, arguments are returned in registers, as described in Table 11.

Table 11. Registers for return values

Type

Returned in register:

char, short, int, long and long long

general register 2 (r2)

double and float

floating point register 0 (f0)

Functions shall return float or double values in f0, with float values rounded to single precision. Functions shall return values of type int, long, long long, enum, short and char, or a pointer to any type as unsigned or signed integers as appropriate, zero- or sign-extended to 64 bits if necessary, in r2.

Values of type long double and structures or unions are returned in a storage buffer allocated by the caller.