ARM C编程扩展手册：v7/v8兼容与优化指南

需积分: 10 100 浏览量更新于2024-07-18 收藏 951KB PDF 举报

"ARM C编程扩展手册（IHI0053B）是针对ARMv7和ARMv8架构的C语言操作指南，旨在帮助程序员充分利用ARM架构的同时保持代码的可移植性。该文档由ARM Limited于2011年至2013年发布，版本为1.1，主要关注的关键点包括ACLE（ARM Compiler Language Extensions）、AARCH（Advanced ARM Architecture）、ABI（Application Binary Interface）、C/C++编译器（如armcc和gcc）、内联函数（intrinsic）、宏定义（macro）、特性属性（attribute）、NEON（ARM的向量处理单元）以及SIMD（Single Instruction Multiple Data）和原子操作（atomic）。文档强调了在指定ARM信息中心（http://infocenter.arm.com/）获取最新版本的重要性，如果用户使用的版本过旧，应前往开发者指南和文章分类下的软件开发部分查找。对于发现的缺陷或错误，用户被鼓励报告至armdotacle@arm.com。在使用此手册时，需要注意的是，它遵循了ARM公司提供的 royalty-free limited license，具体条款在第1.4节（ARM合同参考LEC-PRE-00530）中有详细说明。下载或使用此规范意味着用户同意接受所有条款。若不遵守这些规定，可能会对用户的权益产生影响。因此，在进行ARM C编程时，了解并遵循ARM CLang语言扩展的标准是非常重要的，这将有助于优化程序性能，同时确保代码能够在各种ARM平台上稳定运行。"

3 INTRODUCTION

Modern computer architectures (such as ARM) include architectural features that go beyond the set of operations

available in C/C++. These features may include SIMD and saturating instructions. Exploiting these features to

improve program efficiency has in the past caused “lock-in” to compilers, or to individual CPUs.

The intention of the ARM C Language Extensions (ACLE) is to allow the writing of applications and middleware

code that is portable across compilers, and across ARM architecture variants, while exploiting the unique features

of the ARM architecture family.

The design principles for ACLE can be summarized as:

be implementable in (or as an addition to) current C/C++ implementations

build on and standardize existing practice where possible

Notably, ACLE standardizes the NEON (Advanced SIMD) intrinsics.

ACLE incorporates some language extensions introduced in the GCC C compiler. Current GCC documentation

[GCC] can be found at http://gcc.gnu.org/onlinedocs/gcc. Formally it should be assumed that ACLE refers to the

documentation for GCC 4.5.1: http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/.

Some of the ACLE extensions are not specific to the ARM architecture but have proven to be of particular benefit

in low-level and systems programming; examples include features for controlling the alignment and packing of

data, and some common operations such as word rotation and reversal. As and when features become available

in international standards (and implementations), it is recommended to use these in preference to ACLE. When

implementations are widely available, any ACLE-specific features can be expected to be deprecated.

3.1 ACLE and 64-bit architectures

This revision of ACLE is intended to be efficiently implementable on 64-bit architectures, and to aid in writing code

that runs efficiently on both 32-bit and 64-bit architectures.

Full support for features introduced in 64-bit architectures will be added in future revisions of ACLE.

3.2 Change history

The following sections highlight changes which implementors should be aware of. For tracking purposes the

internal defect references (e.g. “[ACLE-123]”) are given.

4 C LANGUAGE EXTENSIONS

4.1 Fundamental data types

This section overlaps with the specification of the ARM Procedure Call Standard, particularly [AAPCS 4.1]. ACLE

extends C by providing some types not present in Standard C and defining how they are dealt with by the AAPCS.

It also extends some of the guarantees of C, allowing assumptions to be made in source code beyond those

permitted by Standard C.

Plain „char‟ is unsigned, as specified in the ABI [AAPCS 7.1.1].

When pointers are 32 bits, the „long‟ type is 32 bits (ILP32 model).

When pointers are 64 bits, the „long‟ type may be either 64 bits (LP64 model) or 32 bits (LLP64 model).

This release of ACLE does not deal with platforms with 64-bit pointers.

4.1.1 Implementation-defined type properties

ACLE and the ARM ABI allow implementations some freedom in order to conform to long-standing conventions in

various environments. It is suggested that implementations set suitable defaults for their environment (and

document what these are) but allow the default to be overridden.

The signedness of a plain „int‟ bit-field is implementation-defined [C99 6.7.2#4].

Whether the underlying type of an enumeration is minimal or at least 32-bit, is implementation-defined. The

predefined macro __ARM_SIZEOF_MINIMAL_ENUM should be defined as 1 or 4 according to the size of a minimal

enumeration type such as enum { X=0 }.

wchar_t may be 2 or 4 bytes. The predefined macro __ARM_SIZEOF_WCHAR_T should be defined as the same

number.

Where an implementation conforms to the ARM ABI, an object that is sensitive to implementation-defined settings

must indicate those settings in object build attributes, e.g. Tag_ABI_enum_size and Tag_ABI_PCS_wchar_t,

as specified in [BA]. See also section 6.8.

4.1.2 Half-precision floating-point

The __fp16 type denotes half-precision (16-bit) floating-point. It is not required to be provided when not

implemented in hardware. The recommended way to test for this hardware support is to test bit 1 in __ARM_FP.

Implementations which support 16-bit floating-point support two formats: the “binary16” format defined in [IEEE-

FP], and an alternative format, defined by ARM, which extends the range by removing support for infinities and

NaNs. Both formats are described in [ARM ARM A2.7.4]. Toolchains are not required to support the alternative

format. The format in use can be selected at runtime but ACLE assumes it is fixed for the life of a program. If 16-

bit floating-point is available, one of __ARM_FP16_FORMAT_IEEE and __ARM_FP16_FORMAT_ALTERNATIVE will be

defined to indicate the format in use. An implementation conforming to the ARM ABI will set the

Tag_ABI_FP_16bit_format build attribute.

16-bit floating point is a storage and interchange format only. Values of __fp16 type promote to (at least) float

when used in arithmetic operations, in the same way that values of char or short types promote to int. There

is no arithmetic directly on 16-bit values.

Conversion from 64-bit to 16-bit, i.e. from double to __fp16, must round only once. (With round-to-nearest,

converting first to 32-bit and then to 16-bit could give an incorrectly rounded result.) Because in current ARM

hardware floating-point architectures this is not a primitive operation, it may be faster to convert first to single-

precision and then to half-precision:

double xd;

__fp16 xs = (float)xd;

rather than:

double xd;

__fp16 xs = xd;

__fp16 cannot be used as an argument or result type, though it can be used as a field in a structure passed as an

argument or result, or passed via a pointer. C++ name mangling is “Dh” as defined in [cxxabi], and is the same for

both the IEEE and alternative formats.

In this example, the floating-point addition is done in single (32-bit) precision:

void add(__fp16 *z, __fp16 const *x, __fp16 const *y, int n) {

int i;

for (i = 0; i < n; ++i) z[i] = x[i] + y[i];

}

4.2 Predefined macros

Several predefined macros are defined. Generally these define features of the architecture being targeted, or how

the C/C++ implementation uses the architecture. These macros are detailed in section 6 and there is a summary

table in 6.9. All ACLE predefined macros start with the prefix __ARM.

4.3 Intrinsics

ACLE standardizes intrinsics to access the NEON (Advanced SIMD) extension. These intrinsics are intended to

be compatible with existing implementations. Before using the NEON intrinsics or data types, the <arm_neon.h>

header must be included. The NEON intrinsics are defined in section 12. Note that the NEON intrinsics and data

types are in the user namespace.

ACLE also standardizes other intrinsics to access ARM instructions which do not map directly to C operators –

generally either for optimal implementation of algorithms, or for accessing specialist system-level features.

Intrinsics are defined further in various following sections.

Before using the non-NEON intrinsics, the <arm_acle.h> header should be included.

Whether intrinsics are macros, functions or built-in operators is unspecified. For example:

it is unspecified whether applying #undef to an intrinsic removes the name from visibility

it is unspecified whether it is possible to take the address of an intrinsic

However, each argument must be evaluated at most once. So this definition is acceptable:

#define __rev(x) __builtin_bswap32(x)

but this is not:

#define __rev(x) ((((x) & 0xff) << 24) | (((x) & 0xff00) << 8) | \

(((x) & 0xff0000) >> 8) | ((x) >> 24))

剩余65页未读，继续阅读

uidp3308

粉丝: 0
资源: 3

ARM C编程扩展手册：v7/v8兼容与优化指南

ARM Cortex-A(armV7)编程手册V4.0,armcortexa7是什么处理器,C,C++

ARM架构参考手册ARM V9

基于ARM的高效C语言编程.pdf

ARM Cortex-A(armV8)编程手册V1.0,armv8指令集,C,C++

stm32L编程手册,stm32编程手册中文,C,C++

ARM Cortex-A(armV8)编程手册V1.0,armv8指令集,C,C++源码.zip

stm32L编程手册,stm32编程手册中文,C,C++源码.rar

stm32L编程手册,stm32编程手册中文,C,C++源码.zip

ARM Cortex-A(armV7)编程手册V4.0,armcortexa7是什么处理器,C,C++源码.zip

ARM初学者入门手册

最新资源