logo资料库

ARM指令集和THUMB指令集过程调用的规范文件ATPCS.PDF

第1页 / 共37页
第2页 / 共37页
第3页 / 共37页
第4页 / 共37页
第5页 / 共37页
第6页 / 共37页
第7页 / 共37页
第8页 / 共37页
资料共37页,剩余部分请下载后查看
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
分享到:
收藏