The ARM-THUMB Procedure Call Standard
The ARM-THUMB Procedure Call
Standard
Development Systems Business Unit
Engineering Software Group
Document number:
Date of Issue:
Author:
Authorized by:
SWS ESPC 0002 B-01
24 October, 2000
-
© Copyright ARM Limited 1998, 2000. All rights reserved.
Abstract
This document defines a family of procedure call standards for the ARM and THUMB instruction sets.
Keywords
procedure call, function call, calling conventions
Distribution list
Name
Function
Name
Function
SWS ESPC 0002 B-01
Page 1 of 37
Contents
1
ABOUT THIS DOCUMENT
1.1
1.1.1
1.1.2
Change control
Current status and anticipated changes
Change history
References
Terms and abbreviations
SCOPE
INTRODUCTION
Design goals
Conformance
1.2
1.3
2
3
3.1
3.2
3.3
3.3.1
Processes, the memory model, and the stack
The stack
3.4
Pre-conditions and post-conditions
4
THE BASE STANDARD
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.5
4.6
4.7
4.8
Machine registers
Floating point registers
Subroutine call
Parameter passing
Variable number of parameters (variadic routines)
Fixed number of parameters
Result return
The FPA procedure call standard
The VFP (scalar mode) procedure call standard
The no floating-point hardware procedure call standard
5
THE STANDARD VARIANTS
5.1
5.2
Inter-working between ARM-state and Thumb-state
Read-only position-independence—PIC
The ARM-THUMB Procedure Call Standard
5
5
5
5
5
6
7
8
8
8
8
9
9
10
10
11
11
12
13
13
13
14
14
15
16
16
16
SWS ESPC 0002 B-01
Page 2 of 37
The ARM-THUMB Procedure Call Standard
5.3
5.3.1
5.3.2
Read-write position-independence—PID
Position-independent data addressing
RWPI defined
5.4
5.5
5.6
5.7
5.8
Re-entrant code
Shared libraries
The shared-library data-addressing architecture
Stack limit checking
Chunked stacks
6
STACK UNWINDING
6.1.1
6.1.2 What this standard defines
Background
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
Allowed alternatives for unwinding
Basic routine shape
The stack-moves-once condition
Unwinding a fixed size activation record by interpreting an entry sequence
Unwinding a fixed size activation record by executing an exit sequence
Constraints on frame pointers
Unwinding an activation record using a frame pointer
6.3
The shape of routine entry
7
ARM C AND C++ CONVENTIONS
7.1
7.2
7.3
7.3.1
7.3.2
7.3.3
ANSI C and C++ argument passing conventions
Narrow arguments
Result return
Non-floating-point results
Floating-point results
Value-in-registers result return
7.4
__shared_library
8
RATIONALE FOR ATPCS VARIANTS
8.1
8.2
8.2.1
8.2.2
8.2.3
8.3
8.4
The base standard and its variants
ARM Shared Libraries
Basic static data addressing in a shared-library-using application
Exported data
Base-standard clients
Dynamically loaded libraries
Legacy issues
17
17
17
17
18
18
19
20
21
21
21
21
22
22
22
23
23
24
24
25
25
26
26
26
26
27
27
28
28
29
30
30
31
31
32
SWS ESPC 0002 B-01
Page 3 of 37
8.4.1
8.4.2
Floating point argument passing
Narrow arguments
8.5
Derivation of library variant costs
The ARM-THUMB Procedure Call Standard
32
33
34
SWS ESPC 0002 B-01
Page 4 of 37
The ARM-THUMB Procedure Call Standard
1 ABOUT THIS DOCUMENT
1.1 Change control
1.1.1 Current status and anticipated changes
Release A-05 of this specification is the first public release, the ADS-1.0 release.
Release B-01 is the ADS-1.1 release. The description of parameter passing has been extensively revised, but
where release A-05 can be implemented without major difficulties, the resulting parameter lists are almost always
identical. Differences occur only where release A-05 proved too difficult to implement precisely.
Future releases of this standard are likely to:
o Define more precisely the interaction between this standard and the IEEE754 standard for floating-point
arithmetic.
o Define more precisely the mapping of C, C++, and Java source language entities to the machine-level values
passed as parameters across publicly visible interfaces.
1.1.2 Change history
Issue
Date
By
Change
A-01
A-01
A-02
A-03
A-04
A-05
B-01
18 March, 1998
20 March, 1998
30 March, 1998
17 July, 1998
23 October 1998
5 November, 1998
24 October, 2000
-
-
-
-
-
-
-
First partial draft for early review (WD, HM, SW, EN)
Second partial draft for internal review.
First external-review DRAFT.
Second external-review DRAFT
FINAL internal review DRAFT
Editorial changes following review
Added 8-byte stack alignment motivated by ARM architecture 5.
Revised floating-point argument marshalling after it was found
impossible to implement. Made minor editorial improvements.
1.2 References
This document refers to the following documents.
Ref
Doc No
Author(s)
Title
SWS ESPC 0002 B-01
Page 5 of 37
The ARM-THUMB Procedure Call Standard
1.3 Terms and abbreviations
This document uses the following terms and abbreviations.
Term
PCS
APCS
TPCS
ATPCS
Meaning
Procedure Call Standard
ARM Procedure Call Standard
Thumb Procedure Call Standard
ARM-Thumb Procedure Call Standard
Subroutine, routine
A fragment of program to which control can be transferred that, on completing its
task, returns control to its caller at an instruction following the call.
Procedure
Function
A routine that returns no result value.
A routine that returns a result value. A C/C++ function.
Memory state
The state of the program’s memory, including values in machine registers.
Externally visible [interface]
[An interface] between separately compiled or separately assembled routines.
Activation (call-frame) stack
The stack of routine activation records (call frames).
Variable register, v-register
A register used to hold the value of a variable (usually one local to a routine).
Scratch register, temporary
register
A register used to hold an intermediate value during a calculation (usually, such
values are not named in the program source and have a limited lifetime).
Activation record,
call frame
Parameter
Argument
PIC, PID
The memory used by a routine for saving registers and holding local variables
(usually allocated on a stack, once per activation of the routine).
A formal parameter of a routine given the value of the actual parameter when the
routine is called.
Formal parameter or actual parameter according to context.
Position-independent code, position-independent data.
More specific terminology is defined when it is first used.
SWS ESPC 0002 B-01
Page 6 of 37
The ARM-THUMB Procedure Call Standard
2 SCOPE
This standard defines how subroutines can be separately written, separately compiled, and separately assembled
to work together. It describes a contract between a calling routine and a called routine that defines:
o Obligations on the caller to create a memory state in which the called routine may start to execute.
o Obligations on the called routine to preserve the memory-state of the caller across the call.
o The rights of the called routine to alter the memory-state of its caller.
The standard also defines how an external agent can unwind the subroutine activation stack.
This standard specifies a family of Procedure Call Standard (PCS) variants, generated by a cross product of user-
choices that reflect alternative priorities among:
o Code size.
o Performance.
o Functionality (for example, ease of debugging, run-time checking, support for shared libraries).
Many of the variants generated are not compatible with one another because the choices on which they are based
are mutually exclusive or incompatible.
This standard is presented in four sections that specify:
o A machine-level base standard.
o A set of machine-level variants.
o Constraints on the layout of activation records and function entry sequences to support stack unwinding.
o The representation of externally visible C-language—and C++ extern "C" {...}—entities.
This specification does not standardize the representation of externally visible C++-language entities that are not
also C language entities and it places no requirements on the representation of language entities that are not
visible across external interfaces.
SWS ESPC 0002 B-01
Page 7 of 37
The ARM-THUMB Procedure Call Standard
3 INTRODUCTION
This standard embodies the fourth major revision of the APCS and second major revision of the TPCS. It is the
first revision to unify the APCS and the TPCS.
3.1 Design goals
The goals of the ATPCS are to:
o Support Thumb-state and ARM-state equally.
o Support inter-working between Thumb-state and ARM-state.
o Favor:
- Small code-size.
- Functionality appropriate to embedded applications.
- High performance.
And where these aims conflict significantly, to standardize variants covering different priorities among them.
o Clearly distinguish between mandatory requirements and implementation discretion.
o Support alternative floating-point architectures and instruction sets.
o Be binary compatible with:
- The most commonly used variant of the previous APCS.
- The most commonly used variant of the previous TPCS.
3.2 Conformance
This standard defines how separately compiled and separately assembled routines can work together. There is an
externally visible interface between such routines. It is common that not all the externally visible interfaces to
software are intended to be publicly visible or open to arbitrary use. In effect, there is a mismatch between the
machine-level concept of external visibility—defined rigorously by an object code format—and a higher level,
application-oriented concept of external visibility—which is system-specific or application-specific.
Conformance to this standard requires:
o Conformance to the caller-callee contract at all publicly visible interfaces.
o Ubiquitous conformance to its rules of stack usage.
3.3 Processes, the memory model, and the stack
This standard applies to a single thread of execution or process (the terms will be used interchangeably). A thread
of execution, or process, has a memory state defined by the contents of the underlying machine registers and the
contents of the memory it can address. Memory addresses are unsigned integers.
The memory a process can address and access, without causing a run-time fault, may vary during the execution
of the process.
The process can read and write the stack memory. Stack memory may be statically allocated (before run time) or
dynamically allocated (at run time).
SWS ESPC 0002 B-01
Page 8 of 37