A. ABI Considerations

A compiler converts the source code into an object module. The linker resolves cross-references between one or more object modules to form an executable module. The loader converts an executable module into an executable memory image.

An Application Binary Interface (ABI) includes a set of conventions that allows a linker to combine separately compiled and assembled elements of a program so that they can be treated as a unit. The ABI defines the binary interfaces between compiled units and the overall layout of application components comprising a single task within an operating system. Therefore, most compilers target an ABI. The requirements and constraints of the ABI relevant to the compiler extend only to the interfaces between shared system elements. For those interfaces totally under the control of the compiler, the compiler writer is free to choose any convention desired, and the proper choice can significantly improve performance.

IBM has defined three ABIs for the PowerPC architecture: the AIX ABI for big-endian 32-bit PowerPC processors and the Windows NT and Workplace ABIs for little-endian 32-bit PowerPC processors. Other PowerPC users have defined other ABIs. As a practical matter, ABIs tend to be associated with a particular operating system or family of operating systems. Programs compiled for one ABI are frequently incompatible with programs compiled for another ABI because of the low-level strategic decisions required by an ABI. As a framework for the description of ABI issues in this book, we describe the AIX ABI for big-endian, 32-bit systems. For further details, check relevant AIX documentation, especially the Assembler Language Reference manual (IBM Corporation [1993a]). The AIX ABI is nearly identical to what was previously published as the PowerOpen ABI.

The AIX ABI supports dynamic linking in order to provide efficient support for shared libraries. Dynamic linking permits an executable module to link functions in a shared library module during loading.

A.1 Procedure Interfaces

The procedure (or subroutine) is the fundamental element of execution and, with the exception of references to globally defined data and external procedures, represents a closed unit. Many compilers make the procedure the fundamental unit of compilation and do not attempt any interprocedural optimization. An ABI specifies conventions for the interprocedure interfaces.

The interface between two procedures is defined in terms of the caller and the callee. The caller computes parameters to the procedure, binds them to arguments, and then transfers control to the callee. The callee uses the arguments, computes a value (possibly null), and then returns control to the statement following the call. The details of this interface constitute much of the content of the ABI.

When a procedure is called, some prolog code may be executed to create an a block of storage for the procedure on the run-time stack, called an activation record, before the procedure body is executed. When the procedure returns, some epilog code may be executed to clean up the state of the run-time stack.

A.1.1 Register Conventions

Figure A-1. AIX ABI Register Usage Conventions

Register Type	Register	Status	Use
General- Purpose	GPR0	Volatile	Used in function prologs.
	GPR1	Dedicated	Stack Pointer.
	GPR2	Dedicated	Table of Contents (TOC) Pointer.
	GPR3	Volatile	First argument word; first word of function return value.
	GPR4	Volatile	Second argument word; second word function return value.
	GPR5	Volatile	Third argument word.
	GPR6	Volatile	Fourth argument word.
	GPR7	Volatile	Fifth argument word.
	GPR8	Volatile	Sixth argument word.
	GPR9	Volatile	Seventh argument word.
	GPR10	Volatile	Eighth argument word.
	GPR11	Volatile	Used in calls by pointer and as an environment pointer.
	GPR12	Volatile	Used for special exception handling and in glink code.
	GPR13:31	Non-volatile	Values are preserved across procedure calls.
Floating-Point	FPR0	Volatile	Scratch register.
	FPR1	Volatile	First floating-point parameter; first floating-point scalar return value.
	FPR2	Volatile	Second floating-point parameter; second floating-point scalar return value.
	FPR3	Volatile	Third floating-point parameter; third floating-point scalar return value.
	FPR4	Volatile	Fourth floating-point parameter; fourth floating-point scalar return value.
	FPR5	Volatile	Fifth floating-point parameter.
	FPR6	Volatile	Sixth floating-point parameter.
	FPR7	Volatile	Seventh floating-point parameter.
	FPR8	Volatile	Eighth floating-point parameter.
	FPR9	Volatile	Ninth floating-point parameter.
	FPR10	Volatile	Tenth floating-point parameter.
	FPR11	Volatile	Eleventh floating-point parameter.
	FPR12	Volatile	Twelfth floating-point parameter.
	FPR13	Volatile	Thirteenth floating-point parameter.
	FPR14:31	Non-volatile	Values are preserved across procedure calls.
Special-Purpose	LR	Volatile	Branch target address; procedure return address.
	CTR	Volatile	Branch target address; loop count value.
	XER	Volatile	Fixed point exception register.
	FPSCR	Volatile	Floating-point status and control register.
Condition Register	CR0, CR1	Volatile	Condition codes.
	CR2, CR3, CR4	Non-volatile	Condition codes.
	CR5, CR6, CR7	Volatile	Condition codes.

A.1.2 Run-Time Stack

To examine the structure of the run-time stack, consider the following sequence of procedure calls: aaa calls bbb calls ccc calls ddd. Figure A-2 on page 162 shows the relevant areas of the run-time stack for procedure ccc. These areas include:

• bbb's Argument Build Area—ccc recognizes this area as its input parameter area. It is at least eight words long and must be doubleword aligned. It defines the home location of the subprogram arguments. The size of this area must be equal to or greater than the space required for the argument list used by any subprogram called by bbb. Ownership of this area of the stack is yielded to the called subprogram (in this case ccc) at the point of the call and hence must be regarded as volatile across call boundaries.
• bbb's Link Area—The six words contain (offsets are relative to the stack pointer before calling ccc):
  • Offset 0—Back chain to aaa (i.e., the stack pointer before calling bbb).
  • Offset 4—ccc saves the Condition Register here if it modifies any of its nonvolatile fields.
  • Offset 8—ccc saves the Link Register here if it calls another function or uses the Link Register for another purpose.
  • Offset 12—Reserved for compiler use.
  • Offset 16—Reserved for binder use.
  • Offset 20—The glink or ptrgl routines save the address of the TOC from GPR2 here if bbb executes an out-of-module call.
• ccc's FPR Save Area—Save area for any non-volatile Floating-Point Registers used by ccc. This area must be double-word aligned. The non-volatile Floating-Point Registers that the procedure uses are saved immediately adjacent to bbb's link area. The space required ranges from 0 to 144 bytes.
• ccc's GPR Save Area—Save area for any non-volatile general-purpose registers used by ccc. The non-volatile General-Purpose Registers that the procedure uses are saved immediately adjacent to ccc's FPR save area at a negative displacement from the stack pointer before calling ccc. The required space ranges from 0 to 76 bytes.
• Alignment Padding—Space inserted in order to quadword-align the stack pointer.
• ccc's Local Stack Area—Local variables and temporary space for the owner that addresses this region by offset from the stack pointer.
• ccc's Argument Build Area—The description of this area is analogous to the for bbb's argument build area. This area is at least eight words long and must be doubleword aligned. It defines the home location of the subprogram arguments. The size of this area must be equal to or greater than the space for argument storage used by any subprogram called by ccc.
• ccc's Link Area—The six words contain (offsets are relative to the stack pointer after the ccc prolog):
  • Offset 0—Back chain to bbb (i.e., the previous stack pointer).
  • Offset 4—ddd saves the Condition Register here if it modifies any nonvolatile fields.
  • Offset 8—ddd saves the Link Register here if it calls another function or uses the Link Register for another purpose.
  • Offset 12—Reserved for compiler use.
  • Offset 16—Reserved for binder use.
  • Offset 20—The glink or ptrgl routines save the address of the TOC from GPR2 here if ccc executes an out-of-module call.

A.1.3 Leaf Procedures

A.2 Procedure Calling Sequence

The argument-passing rules provide the maximum level of support for inter-language calls and facilitate consistent handling of calls between mismatched or incorrectly prototyped C function definitions. Compilers may discover and exploit the properties of individual calls (e.g., through the use of prototypes), and thereby modify various parts of the following description; however, the program behavior must appear as if the rules were applied uniformly. The argument-passing rules are:

• All parameters to a subprogram, regardless of type, are mapped into the argument build area such that the home location of each subprogram argument is appropriately defined for its type. That is, if an actual parameter were stored to the home location, the value obtained by a corresponding load instruction referencing the argument's home location is the same as the actual parameter.
• The values corresponding to the first eight words of the input parameter area are passed in General-Purpose Registers GPR3:10, inclusive.
• Up to 13 floating-point parameters, if they exist, are passed in the Floating-Point Registers FPR1:13, inclusive. Any floating-point values that extend beyond the first 8 words of the argument list must also be stored at the corresponding location on the stack.
• If the called subprogram requires addressability to its parameter area, it is sufficient to store GPR3:10 to their corresponding locations on the stack, thus initializing the home locations of any parameters passed in registers.

void foo1(long a, short b, char c);

Figure A-3. Argument Passing for foo1

Argument	Type	Argument Words in Build Area	Registers
			General-Purpose	Floating-Point
a	long	(0)	GPR3	—
b	short	(1)	GPR4	—
c	char	(2)	GPR5	—
() indicate that the resource is reserved on the stack or in the register, but the value may not be present.

Figure A-4 shows how the arguments are passed for another function that has both integer and floating-point values:

void foo2(long a, double b, float c, char d,
double e, double f, short g, float h);

Figure A-4. Argument Passing for foo2

Argument	Type	Argument Words in Build Area	Registers
			General-Purpose	Floating-Point
a	long	(0)	GPR3	—
b	double	(1:2)	(GPR4:5)	FPR1
c	float	(3)	(GPR6)	FPR2
d	char	(4)	GPR7	—
e	double	(5:6)	(GPR8:9)	FPR3
f	double	(7),8 (The word at 32 contains the low-order half of f)	(GPR10) (high-order part of f)	FPR4
g	short	9	—	—
h	float	10	—	FPR5
() indicate that the resource is reserved on the stack or in the register, but the value may not be present.

The first 8 words of the argument list are passed in registers. This example assumes that the function prototype is visible at the point of the call; hence, floating-point parameters need not be copied to the General-Purpose Registers.

A.2.2 Function Return Values

• Values of type int, long, short, pointer, and char (length less than or equal to four bytes), as well as bit values of lengths less than or equal to 32 bits, are returned right-justified in GPR3, sign-extended or not as appropriate.
• If the called subprogram returns an aggregate, there exists an implicit first argument, whose value is the address of a caller-allocated buffer into which the callee is assumed to store its return value. All explicit parameters are appropriately relabeled.
• Eight-byte non-floating-point scalar values must be returned in GPR3:GPR4.
• Scalar floating-point values are returned in FPR1 for float or double, and in FPR1:FPR2 for quadword precision. Fortran complex*8 and complex*16 are returned in FPR1:FPR2, and complex*32 is returned in FPR1:FPR4.

Prolog code is responsible for establishing a new activation record and saving on the stack any state that must be preserved:

• If the Link Register will be used (for another call or for a computed jump), save it at offset 8 from the stack pointer.
• If any of the non-volatile Condition Register fields will be used, save the Condition Register at offset 4 from the stack pointer.
• If any non-volatile Floating-Point Registers will be used, save them in the FPR save area.
• If any non-volatile General-Purpose Registers will be used, save them in the GPR save area.
• If a new activation record is required, sum the following items to determine the new stack pointer's displacement from the current stack pointer:
  • 8*(number of non-volatile Floating-Point Registers saved)
  • 4*(number of General-Purpose Registers saved)
  • size in bytes of the local stack area
  • 4*(maximum number of argument words for any called procedure)
  • 24 (the fixed size of the link area)
  • the number of bytes required to align the stack frame

stwu R1,-offset(R1).

If the displacement is greater than or equal to 2¹⁵, load the offset into R3 and use:

stwux R1,R1,R3.

Epilog code is responsible for unwinding and deallocating the activation record:

• If a new activation record was acquired, restore the old stack pointer. If the relative displacement between the current and previous stack pointers is less than 2¹⁵, simply add the displacement to the current stack pointer. For procedures that call alloca() to dynamically increase the size of the local storage area or that have a displacement between the current and previous stack pointers greater than 2¹⁵, load the previous stack pointer from the stack.
• If any non-volatile General-Purpose Registers were altered, restore them.
• If any non-volatile Floating-Point Registers were altered, restore them.
• If any non-volatile Condition Register fields were altered, restore them (mtcrf instruction).
• If the Link Register was altered, restore it.
• Return to the caller using the value in the Link Register.

The content of the prolog and epilog code involves a number of trade-offs. For example, if the number of General-Purpose Registers and Floating-Point Registers that need to be saved is small, the saves should be generated in-line. If there are many registers to be saved, the save and restore could be done with a system routine at the cost of a branch and link and return. For a high performance machine, the branch penalty may be substantial and needs to be traded-off against the additional code (and instruction cache penalties) associated with doing the saves and restores in-line. Although load and store multiple instructions could be used, scalar loads and stores offer better performance for some implementations. Also, they do not function in Little-Endian mode.

A.3 Dynamic Linking

A.3.1 Table Of Contents

Variables that are visible outside of the module are accessed using the TOC. The address of the variable is stored in the TOC at a compiler-known offset. The value may be accessed as follows:

lwz R3,offset_&value(RTOC)
lwz R4,0(R3)

To optimize the access of a number of variables, a single reference address may be stored in the TOC, and the different variables may be indexed from this address. Another optimization is to directly store the value of the variable in the TOC:

lwz R3,offset_value(RTOC)

A.3.2 Function Descriptors

Figure A-5. Function Descriptor

	struct {
	void *(func_ptr)(); /* the address of the function */
	void *toc_value; /* RTOC value for the function */
	void *env; /* environment pointer */
	}

A.3.3 Out-of-Module Function Calls

Figure A-6. main: Function-Calling Code Example

	C Source Code
	extern int printf(char *,...);
	main()
	{
	int (*foo_bar)(char *,...);
	foo_bar = printf;
	foo_bar("Via pointer\n");
	printf("Direct\n");
	}
	Assembly Code
	mflr	R0	# get value of LR
	stw	R31,-4(SP)	# save old R31 in stack
	lwz	R31,.CONSTANT(RTOC)	# get address of strings
	stw	R0,8(SP)	# save LR in callers stack frame
	stwu	SP,-80(SP)	# create activation record
	lwz	R11,.printf(RTOC)	# get &(function descriptor)
	mr	R3,R31	# string address to parameter 1
*	bl	.ptrgl	# call pointer glue
*	lwz	RTOC,20(SP)	# reload RTOC from stack frame
	addi	R3,R31,16	# string address to parameter 1
*	bl	.printf	# call printf via glink code
*	ori	R0,R0,0	# reload RTOC from stack frame
	lwz	R12,88(SP)	# reload old LR
	lwz	R31,76(SP)	# restore R31
	mtlr	R12	# load LR
	addi	SP,SP,80	# remove activation record
	blr		# return via LR

The function call by pointer uses a system routine, ptrgl, shown in Figure A-7. The "." immediately preceding the function name in the assembly listing is a linker convention indicating that the address of the function is represented by the symbol. The ptrgl routine performs a control transfer to an external function whose address is unknown at compile-link time. On entry, it assumes that GPR11 contains the address of the function descriptor for the function being called. The ptrgl routine acts as a springboard to the external function, which will return directly to the call point and not to ptrgl. A compiler may inline the code for ptrgl.

Figure A-7. ptrgl Routine Code Sequence

	lwz	R0,0(R11)	# load function's address
	stw	RTOC,20(SP)	# save RTOC in stack frame
	mtctr	R0	# CTR = function address
	lwz	RTOC,4(R11)	# RTOC = callee's RTOC
	lwz	R11,8(R11)	# R11 = environment of callee
	bctr		# transfer to function

When an external function is called by name, the linker injects a call to a global linkage (glink) routine and replaces the no-op with code to restore the caller's TOC address in RTOC on return:

bl .glink_printf # call glink for printf
lwz RTOC,20(SP) # restore TOC pointer

Figure A-8 shows the glink routine, which intercepts the call to the out-of-module function, obtains the location of the callee's function descriptor from the TOC, saves the caller's RTOC value, load RTOC with the callee's TOC address, and transfers control to the function as in the case of call by pointer. This springboard code is unique for each procedure and is generated at link time.

Figure A-8. glink_printf Code Sequence

	lwz	R12,.printf(RTOC)	# get address of descriptor
	stw	RTOC,20(SP)	# save RTOC in stack frame
	lwz	R0,0(R12)	# load function address
	lwz	RTOC,4(R12)	# RTOC = callee's RTOC
	mtctr	R0	# CTR = function address
	bctr		# transfer to function

Statically (compiler-time) bound procedures do not need springboard code and can be compiled without the no-op following the branch and link. The linker introduces the springboard code only when necessary. If the called routine is linked to the same module as its caller, then the compiled code sequence is unchanged; that is, the branch and link target is not directed to the springboard code and the no-op remains (control transfers directly to the called function).