S/390 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. S/390 processors have 16 general purpose registers; newer models have 16 IEEE floating point registers but older systems have only four non-IEEE floating point registers. On these older machines Linux for S/390 emulates 16 IEEE registers within the kernel. The width of the general purpose registers is 32 bits, and the width of the floating point registers is 64 bits. 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 | Saved | |
General purpose | Volatile | |
Access register 0 | Reserved for system use | Volatile |
Access registers 1-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, f4 and f6 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, f1, f2, f3, f5, f6 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 15 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 96 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 S/390, the following applies:
General registers r2 to r6 are used for integer values.
Floating point registers f0 and f2 are used for floating point values.
Beside these general rules the following rules apply:
char, short and int are passed in general registers.
long long are passed in two consecutive general registers if the next available register is smaller than 6. If the upper 32 bits would end in general register 6 then this register is skipped and the whole 64 bit value is passed on the stack.
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 quivalent to a floating point type.
Structures with a size of 1, 2, or 4 bytes which are not equivalent to a floating point type are passed as integral values.
Structures with a size of 8 bytes which are not equivalent to a floating point type are passed as an integal value in two registers.
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 32 bits wide (char, short, int, long, enum).
A pointer to an object of any type.
A struct or a union of 1, 2 or 4 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 32 bits are sign- or zero-extended (as appropriate) to 32 bits.
A DOUBLE_ARG is one of type long long, or is a struct or a union of size 8 bytes which is not a structure equivalent to a floating point type.
If gr>5 set gr to 7 and go to OTHER. Load the lower-addressed word of the long long into gr and the higher-addressed word into gr+1, set gr to gr+2, and go to SCAN.
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 a size of 4 bytes, where simple interger types shorter than 4 bytes are signed or zero-extended (as appropriate) to 4 bytes, and other arguments of size less than 4 bytes will be placed right-justified into a 4 byte slat. float arguments have a size of 4 bytes; long long and double arguments have a size of 8 bytes.
Coy the argument to the current stack position starg, using the argument size of 4 or 8 bytes as given above. Increment starg by the argument size, then go to SCAN.
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 18. The corresponding register allocation and storage would be as shown in Table 10.
Table 10. Parameter passing example: Register allocation
General purpose registers | Floating-point registers | Stack frame offset |
---|---|---|
r2: i | f0: g | 96: ll |
r3: j | f2: f | 104: h |
r4: k | 112: m | |
r5: l | ||
r6: - |
In this example r6 is unused as the long long variable ll will not fit into a single register.
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 the ESA/390 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 S/390 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 and long | general register 2 (r2) |
long long | general registers 2 and 3 (r2, r3) |
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, enum, short and char, or a pointer to any type as unsigned or signed integers as appropriate, zero- or sign-extended to 32 bits if necessary, in r2.
Values of type long long and unsigned long long shall be returned with the lower addressed half in r2 and the higher in r3.
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 |