zSeries ELF Application Binary Interface Supplement | ||
---|---|---|
<<< Previous | Low-level system information | Next >>> |
This section discusses the standard function calling sequence, including stack frame layout, register usage, and parameter passing.
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 |
---|---|---|
General purpose | Volatile¹ | |
Parameter passing and return values | Volatile | |
Parameter passing | Volatile | |
Parameter passing | Saved² | |
Local variables | Saved | |
Local variable, commonly used as GOT pointer | Saved | |
Local variable, commonly used as Literal Pool pointer | Saved | |
Return address | Volatile | |
Stack pointer | Saved | |
Parameter passing and return values | Volatile | |
General purpose | Volatile | |
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. |
Registers r6 through r13, r15, f1, f3, f5 and f7 are nonvolatile; that is, they "belong" to the calling function. A called function shall save these registers' values before it changes them, restoring their values before it returns.
Registers r0, r1, r2, r3, r4, r5, r14, f0, f2, f4, f6, f8 through f15 are volatile; that is, they are not preserved across function calls.
Furthermore the values in registers r0 and r1 may be altered by the interface code in cross-module calls, so a function cannot depend on the values in these registers having the same values that were placed in them by the caller.
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.
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.
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.
The format of the register save area created by the gcc compiler is:
The following requirements apply to the stack frame:
The stack pointer shall maintain 8-byte alignment.
The stack pointer points to the first word of the lowest allocated stack frame. If the "back chain" is implemented this word will point to the previously allocated stack frame (towards higher addresses), except for the first stack frame, which shall have a back chain of zero (NULL). The stack shall grow downwards, in other words towards lower addresses.
The called function may create a new stack frame by decrementing the stack pointer by the size of the new frame. This is required if this function calls further functions. The stack pointer must be restored prior to return.
The parameter list area shall be allocated by the caller and shall be large enough to contain the arguments that the caller stores in it. Its contents are not preserved across calls.
Other areas depend on the compiler and the code being compiled. The standard calling sequence does not define a maximum stack frame size.
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.
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:
General registers r2 to r6 are used for integer values.
Floating point registers f0, f2, f4 and f6 are used for floating point values.
Beside these general rules the following rules apply:
char, short, int, long and long long are passed in general registers.
Structures equivalent to a floating point type are passed in floating point registers. A structure is equivalent to a floating point type if and only if it has exactly one member, which is either of floating point type of itself a structure equivalent to a floating point type.
Structures with a size of 1, 2, 4, or 8 bytes which are not equivalent to a floating point type are passed as integral values.
All other structures are passed by reference. If needed, the called function makes a copy of the value.
Complex numbers are passed as structures.
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.
Set fr=0, gr=2, and starg to the address of parameter word 1.
If there are no more arguments, terminate. Otherwise, select one of the following depending on the type of the next argument:
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.
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.
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.
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.
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.
<<< Previous | Home | Next >>> |
Low-level system information | Up | Operating system interface |