The Itanium™ Architecture is specified by the following documents
Only the features of the Itanium™ processor instruction set may be assumed to be present. An application should determine if any additional instruction set features are available before using those additional features. If a feature is not present, then the application may not use it.
Conforming applications may use only instructions which do not require elevated privileges.
Conforming applications shall not invoke the implementations underlying system call interface directly. The interfaces in the implementation base libraries shall be used instead.
Rationale: Implementation-supplied base libraries may use the system call interface but applications must not assume any particular operating system or kernel version is present.
There are some features of the Itanium™ processor architecture that need not be supported by a conforming implementation. These are described in this chapter. A conforming application shall not rely on these features.
Applications conforming to this specification must provide feedback to the user if a feature that is required for correct execution of the application is not present. Applications conforming to this specification should attempt to execute in a diminished capacity if a required feature is not present.
This specfication does not provide any performance guarantees of a conforming system. A system conforming to this specification may be implemented in either hardware or software.
This specification describes only LP64 (i.e. 32-bit integers, 64-bit longs and pointers) based implementations. Implementations may also provide ILP32 (32-bit integers, longs, and pointers), but conforming applications shall not rely on support for ILP32. See section 1.2 of the Intel® Itanium™ Processor-specific Application Binary Interface for further information.
The following sections, in conjunction with section 4 of Itanium™ Software Conventions and Runtime Guide, define the size, alignment requirements, and hardware representation of the standard C data types.
Within this specification, the term byte refers to an 8-bit object, the term halfword refers to a 16-bit object, the term word refers to a 32-bit object, the term doubleword refers to a 64-bit object, and the term quadword refers to a 128-bit object.
LSB-conforming applications shall use little-endian byte ordering. LSB-conforming implementations may support big-endian applications.
Table 8-1 describes how fundemental C language data types shall be represented:
Table 8-1. Scalar Types
|Type||C||sizeof||Alignment (bytes)||Hardware Representation|
|Integral||_Bool||1||1||byte (sign unspecified)|
|unsigned char||signed byte|
|unsigned short||unsigned halfword|
|unsigned int||unsigned word|
|unsigned long||unsigned doubleword|
|long long||8||8||signed doubleword|
|signed long long|
|unsigned long long||unsigned doubleword|
|Pointer||any-type *||8||8||unsigned doubleword|
|long double||16||16||IEEE Double-extended|
A null pointer (for all types) shall have the value zero.
Aggregates (structures and arrays) and unions assume the alignment of their most strictly aligned component. The size of any object, including aggregates and unions, shall always be a multiple of the object's alignment. An array uses the same alignment as its elements. Structure and union objects may require padding to meet size and element constraints. The contents of such padding is undefined.
An entire structure or union object shall be aligned on the same boundary as its most strictly aligned member.
Each member shall be assigned to the lowest available offset with the appropriate alignment. This may require internal padding, depending on the previous member.
A structure's size shall be increased, if necessary, to make it a multiple of the alignment. This may require tail padding, depending on the last member.
A conforming application shall not read padding.
Figure 8-1. Structure Smaller Than A Word
|Doubleword Aligned, sizeof is 16|
|Offset||Byte 3||Byte 2||Byte 1||Byte 0|
Figure 8-2. No Padding
C struct and union definitions may have bit-fields, which define integral objects with a specified number of bits.
Bit fields that are declared with neither signed nor unsigned specifier shall always be treated as unsigned. Bit fields obey the same size and alignment rules as other structure and union members, with the following additional properties:
Bit-fields are allocated from right to left (least to most significant).
A bit-field must entirely reside in a storage unit for its appropriate type. A bit field shall never cross its unit boundary.
Bit-fields may share a storage unit with other struct/union members, including members that are not bit fields. Such other struct/union members shall occupy different parts of the storage unit.
The type of unnamed bit-fields shall not affect the alignment of a structure or union, although individual bit-field member offsets shall obey the alignment constraints.
|Bit-field Type||Width w||Range|
|1 to 8|
|1 to 16|
|1 to 32|
|1 to 64|
Figure 8-4. Bit-Field Ranges