Processor Identification Registers

Application level processor identification information is available in a register file termed: CPUID. This register file is divided into a fixed region, registers 0 to 4, and a variable region, register 5 and above. The CPUID[3].number field indicates the maximum number of 8-byte registers containing processor specific information. The CPUID registers are unprivileged and accessed using the indirect mov (from) instruction. All registers beyond register CPUID[3].number are reserved and raise a Reserved Register/Field fault if they are accessed. Writes are not permitted and no instruction exists for such an operation.

Vendor information is located in CPUID registers 0 and 1 and specify a vendor name, in ASCII, for the processor implementation (Figure 3-10). All bytes after the end of the string up to the 16th byte are zero. Earlier ASCII characters are placed in lower number register and lower numbered byte positions.

CPUID register 2 is an ignored register (reads from this register return zero).

CPUID register 3 contains several fields indicating version information related to the processor implementation. Figure 3-11 and Table 3-7 specify the definitions of each field.

up 2 User performance monitor enable (including IA-32) 0: user performance monitors are disabled 1: user performance monitors are enabled

ac 3 Alignment check for data memory references (including IA-32)

0: unaligned data memory references may cause an Unaligned Data Reference fault. 1: all unaligned data memory references cause an Unaligned Data Reference fault. mfl 4 Lower (f2.. f31) floating-point registers written – This bit is set to one when an Intel®

Itanium® instruction that uses register f2..f31 as a target register, completes. This bit is sticky and is only cleared by an explicit write of the user mask. See Section 3.3.2, “Processor Status Register (PSR)” for conditions when IA-32 instructions set this bit. mfh 5 Upper (f32.. f127) floating-point registers written – This bit is set to one when an Intel®

Itanium® _{instruction that uses register f32..f127 as a target register, completes. This bit} is sticky and only cleared by an explicit write of the user mask. See Section 3.3.2, “Processor Status Register (PSR)” for conditions when IA-32 instructions set this bit.

Figure 3-10. CPUID Registers 0 and 1 – Vendor Information

63 0

CPUID[0] byte 0

CPUID[1] byte 15

64

Figure 3-11. CPUID Register 3 – Version Information

63 40 39 32 31 24 23 16 15 8 7 0

rv archrev family model revision number

24 8 8 8 8 8

Table 3-6. User Mask Field Descriptions (Continued)

CPUID register 4 provides general application-level information about processor features. As shown in Figure 3-12, it is a set of flag bits used to indicate if a given feature is supported in the processor model. When a bit is one the feature is supported; when 0 the feature is not supported. The defined feature bits in the current architecture are listed in Table 3-8. As new features are added (or removed) from future processor models the presence (or removal) of new features will be indicated by new feature bits. CPUID register 4 is logically split into two halves, both of which contain general feature and capability information but which have different usage models and access

capabilities; this information reflects the status of any enabled or disabled features. Both the upper and lower halves of CPUID register 4 are accessible through the move indirect register instruction; depending on the implementation, the latency for this access can be long and this access method is not appropriate for low-latency code versioning using self-selection. In addition, the upper half of CPUID register 4 is also accessible using the test feature instruction; the latency for this access is comparable to that of the test bit instruction and this access method enables low-latency code versioning using self selection.

This register does not contain IA-32 instruction set features. IA-32 instruction set features can be acquired by the IA-32 cpuid instruction.

Table 3-7. CPUID Register 3 Fields

Field Bits Description

number 7:0 The index of the largest implemented CPUID register (one less than the number of implemented CPUID registers). This value will be at least 4.

revision 15:8 Processor revision number. An 8-bit value that represents the revision or stepping of this processor implementation within the processor model.

model 23:16 Processor model number. A unique 8-bit value representing the processor model within the processor family.

family 31:24 Processor family number. A unique 8-bit value representing the processor family. archrev 39:32 Architecture revision. An 8-bit value that represents the architecture revision

number that the processor implements.

rv 63:40 Reserved.

Figure 3-12. CPUID Register 4 – General Features/Capability Bits

63 34 33 32 31 4 3 2 1 0

rv x2 cz rv ru ao sd lb

30 1 1 28 1 1 1 1

Table 3-8. CPUID Register 4 Fields

Field Bits Description

lb 0 Processor implements the long branch (brl) instructions.

sd 1 Processor implements spontaneous deferral (see Section 5.5.5, “Deferral of Speculative Load Faults” on page 2:105).

ao 2 Processor implements 16-byte atomic operations (see “ld — Load”, “st — Store” and

“cmpxchg — Compare and Exchange” instructions in Volume 3). ru 3 Processor implements the Resource Utilization Counter (AR 45).

rv 31:4 Reserved.

cz 32 Processor implements the clz instruction (see “tf — Test Feature” instruction in

3.2

Memory

This section describes an Itanium architecture-based application program’s view of memory. This includes a description of how memory is accessed, for both 32-bit and 64-bit applications. The size and alignment of addressable units in memory is also given, along with a description of how byte ordering is handled.

The system view of memory and of virtual memory management is given in Chapter 4, “Addressing and Protection” in Volume 2 . The IA-32 instruction set view of memory and virtual memory management is defined in Section 10.6, “System Memory Model” on page 2:259.

3.2.1

Application Memory Addressing Model

Memory is byte addressable and is accessed with 64-bit pointers. A 32-bit pointer model without a hardware mode is supported architecturally. Pointers which are 32 bits in memory are loaded and manipulated in 64-bit registers. Software must explicitly convert 32-bit pointers into 64-bit pointers before use. For details on 32-bit addressing, refer to “32-bit Virtual Addressing” on page 2:71.

3.2.2

Addressable Units and Alignment

Memory can be addressed in units of 1, 2, 4, 8, 10 and 16 bytes.

It is recommended that all addressable units be stored on their naturally aligned boundaries. Hardware and/or operating system software may have support for

unaligned accesses, possibly with some performance cost. 10-byte floating-point values should be stored on 16-byte aligned boundaries.

Bits within larger units are always numbered from 0 starting with the least-significant bit. Quantities loaded from memory to general registers are always placed in the least-significant portion of the register (loaded values are placed right justified in the target general register).

Instruction bundles (three instructions per bundle) are 16-byte units that are always aligned on 16-byte boundaries.

3.2.3

Byte Ordering

The UM.be bit in the User Mask controls whether loads and stores use little-endian or big-endian byte ordering for Itanium architecture-based code. When the UM.be bit is 0, larger-than-byte loads and stores are little endian (lower-addressed bytes in memory correspond to the lower-order bytes in the register). When the UM.be bit is 1,

x2 33 Processor implements mpy4 and mpyshl4 instructions (see “tf — Test Feature”

instruction in Volume 3).

rv 63:34 Reserved.

Table 3-8. CPUID Register 4 Fields (Continued)

larger-than-byte loads and stores are big endian (lower-addressed bytes in memory correspond to the higher-order bytes in the register). Load byte and store byte are not affected by the UM.be bit. The UM.be bit does not affect instruction fetch, IA-32 references, or the RSE. Instructions are always accessed by the processor as

little-endian units. When instructions are referenced as big-endian data, the instruction will appear reversed in a register.

Figure 3-13 shows various loads in little-endian format. Figure 3-14 shows various loads in big endian format. Stores are not shown but behave similarly.

Figure 3-13. Little-endian Loads

Figure 3-14. Big-endian Loads

a b c d e f g h d c b a h g f e 63 0 0 1 2 3 4 5 6 7 LD8 [0] => 7 0 Memory Registers 0 0 0 b 0 0 0 0 63 0 LD1 [1] => 0 0 d c 0 0 0 0 63 0 LD2 [2] => h g f e 0 0 0 0 63 0 LD4 [4] => Address a b c d e f g h _{63 0} 0 1 2 3 4 5 6 7 LD8 [0] => 7 0 Memory Registers Address e f g h a b c d 63 0 LD4 [4] => 0 0 0 0 e f g h 63 0 LD2 [2] => 0 0 0 0 0 0 c d 63 0 LD1 [1] => 0 0 0 0 0 0 0 b