|
|||
| Products Download Events Support Videos | |||
Technical Support
On-Line Manuals
Compiler User Guide
Conventions and Feedback
Overview of the Compiler
Getting Started with the Compiler
Compiler Features
Compiler Coding Practices
The compiler as an optimizing compiler
Compiler optimization for code size versus speed
Compiler optimization levels and the debug view
Selecting the target CPU at compile time
Optimization of loop termination in C code
Loop unrolling in C code
Compiler optimization and the volatile keyword
Code metrics
Code metrics for measurement of code size and data
Stack use in C and C++
Benefits of reducing debug information in objects
Methods of reducing debug information in objects a
Guarding against multiple inclusion of header file
Methods of minimizing function parameter passing o
Functions that return multiple values through regi
Functions that return the same result when called
Comparison of pure and impure functions
Recommendation of postfix syntax when qualifying f
Inline functions
Compiler decisions on function inlining
Automatic function inlining and static functions
Inline functions and removal of unused out-of-line
Automatic function inlining and multifile compilat
Restriction on overriding compiler decisions about
Compiler modes and inline functions
Inline functions in C++ and C90 mode
Inline functions in C99 mode
Inline functions and debugging
Types of data alignment
Advantages of natural data alignment
Compiler storage of data objects by natural byte a
Relevance of natural data alignment at compile tim
Unaligned data access in C and C++ code
The __packed qualifier and unaligned data access i
Unaligned fields in structures
Performance penalty associated with marking whole
Unaligned pointers in C and C++ code
Unaligned Load Register (LDR) instructions generat
Comparisons of an unpacked struct, a __packed stru
Compiler support for floating-point arithmetic
Default selection of hardware or software floating
Example of hardware and software support differenc
Vector Floating-Point (VFP) architectures
Limitations on hardware handling of floating-point
Implementation of Vector Floating-Point (VFP) supp
Compiler and library support for half-precision fl
Half-precision floating-point number format
Compiler support for floating-point computations a
Types of floating-point linkage
Compiler options for floating-point linkage and co
Floating-point linkage and computational requireme
Processors and their implicit Floating-Point Units
Integer division-by-zero errors in C code
About trapping integer division-by-zero errors wit
About trapping integer division-by-zero errors wit
Identification of integer division-by-zero errors
Examining parameters when integer division-by-zero
Software floating-point division-by-zero errors in
About trapping software floating-point division-by
Identification of software floating-point division
Software floating-point division-by-zero debugging
New language features of C99
New library features of C99
// comments in C99 and C90
Compound literals in C99
Designated initializers in C99
Hexadecimal floating-point numbers in C99
Flexible array members in C99
__func__ predefined identifier in C99
inline functions in C99
long long data type in C99 and C90
Macros with a variable number of arguments in C99
Mixed declarations and statements in C99
New block scopes for selection and iteration state
_Pragma preprocessing operator in C99
Restricted pointers in C99
Additional <math.h> library functions in C99
Complex numbers in C99
Boolean type and <stdbool.h> in C99
Extended integer types and functions in <inttyp
<fenv.h> floating-point environment access i
<stdio.h> snprintf family of functions in C9
<tgmath.h> type-generic math macros in C99
<wchar.h> wide character I/O functions in C9
How to prevent uninitialized data from being initi
Compiler Diagnostic Messages
Using the Inline and Embedded Assemblers of the AR
Compiler User Guide
Performance penalty associated with marking whole structures as packed
| |||
| Home > Compiler Coding Practices > Performance penalty associated with marking whole structures as packed | |||
Reading from and writing to whole structures qualified with __packed requires
unaligned accesses and can therefore incur a performance penalty.
When optimizing a struct that is packed, the
compiler tries to deduce the alignment of each field, to improve
access. However, it is not always possible for the compiler to deduce
the alignment of each field in a __packed struct.
In contrast, when individual fields in a struct are declared
as __packed, fast access is guaranteed to naturally
aligned members within the struct. Therefore, when
the use of a packed structure is required, it is recommended that
you always pack individual fields of the structure, rather than
the entire structure itself.
Note
Declaring individual non-aligned fields of a struct as __packed also
has the advantage of making it clearer to the programmer which fields
of the struct are not naturally aligned.
See also- Concepts
- Reference
Compiler Reference:
| Copyright © 2007-2008, 2011-2012 ARM. All rights reserved. | ARM DUI 0375D |
| Non-Confidential | ID062912 |
 PDF version | |
| Home > Compiler Coding Practices > Performance penalty associated with marking whole structures as packed |
ProductsDevelopment Tools |
Hardware & Collateral |
Downloads |
Support |
Buy |
|
 |
|||
