Fundamental Data Types

The fundamental data types shown in Table 10-1 are, unsurprisingly, sized using integer powers of two. The bits of a fundamental data type are numbered from right to left with 0 and size - 1 used to identify the least and most significant bits, respectively. Fundamental data types larger than a single byte are stored in memory using little-endian byte ordering. Recall from the discussions in Chapter 1 that little-endian byte ordering stores the least significant byte of a multibyte value at the lowest memory address. Figure 10-1 illustrates the bit numbering and byte ordering schemes used by the fundamental data types shown in Table 10-1.

A fundamental data type is properly aligned in memory when its address is an integral multiple of its size in bytes. For example, a doubleword is properly aligned when it is stored at a memory address that is an integral multiple of four. Similarly, a quadword is properly aligned when it is stored at a memory address that is evenly divisible by eight. Unless enabled by the host operating system, an x86-64 processor does not require fundamental data types to be properly aligned in memory. However, it is standard programming practice to properly align all values whenever possible to avoid potential performance penalties that can occur when the processor accesses an improperly aligned data value in memory.

Numerical Data Types

In Table 10-2, note that the size of a C++ long and unsigned long varies. 64-bit versions of Linux use 64-bit wide integers for both long and unsigned long, while 64-bit versions of Windows use 32-bit wide integers for these same types.

SIMD Data Types

The X86 SIMD data types are described in Chapter 1. You can refer to this chapter if you need to refresh your understanding of these types.

Strings

An x86 string is a contiguous block of bytes, words, doublewords, or quadwords. The x86-64 instruction set includes instructions that perform string compare, load, move, scan, and store operations. X86-64 string instructions also can be employed to carry out processing operations using arrays, bitmaps, or similar contiguous-block data structures. For example, the instruction movsb (Move Data from String to String) is often used to copy data bytes from one buffer to another, while the instruction stosb (Store String) can be used to set each element in an array to zero or some other constant value.

General-Purpose Registers

All x86-64 processors contain 16 64-bit wide general-purpose registers. Functions use these registers to perform integer arithmetic, bitwise logical operations, comparisons, address calculations, and data transfers. A function can also store a temporary result in a general-purpose register instead of saving it to memory. Figure 10-3 shows the complete set of x86-64 general-purpose registers along with their operand names.

The low-order doubleword, word, and byte of each 64-bit general-purpose register are independently accessible and can be used to carry out operations using 32-, 16-, or 8-bit wide operands. For example, a function can use registers EAX, EBX, ECX, and EDX to perform 32-bit integer arithmetic in the low-order doublewords of RAX, RBX, RCX, and RDX, respectively. Similarly, registers AL, BL, CL, and DL can be used to perform 8-bit calculations in the low-order bytes. It should be noted that the Intel programming reference manuals use different names for some of the byte registers. This book uses the same register names as the Microsoft 64-bit macro assembler (MASM) to maintain consistency between the text and source code. Not shown in Figure 10-3 are the legacy byte registers AH, BH, CH, and DH. These registers are aliased to the high-order bytes of registers AX, BX, CX, and DX, respectively.

Despite their designation as general-purpose registers, the x86-64 instruction set imposes some notable restrictions on their use. Several instructions either require or implicitly use specific registers as operands. This is a legacy scheme inherited from the 8086 that ostensibly improves code density. For example, some variants of the imul (Multiply Signed Integers) instruction save the calculated product in RDX:RAX, EDX:EAX, DX:AX, or AX. The colon notation used here signifies that the final product is stored in two registers with the first register holding the most significant bits. The idiv (Divide Signed integers) requires the integer dividend to be loaded in RDX:RAX, EDX:EAX, DX:AX, or AX. The x86-64 string instructions use registers RSI and RDI for the source and destination buffers, respectively; string instructions that employ a repeat (or length) count must load this value into register RCX.

The processor uses register RSP to support stack-based operations such as function calls and returns. The stack itself is simply a contiguous block of memory that is assigned to a process or thread by the operating system. Programs can use the stack to preserve registers, pass function arguments, and store temporary results. Register RSP always points to the stack’s top-most item. Stack push and pop operations are performed using 64-bit wide operands. This means that the location of the stack should always be aligned on a quadword (8-byte) boundary. Some 64-bit runtime environments (e.g., Visual C++ programs running on Windows) align stack memory and RSP to a double quadword (16-byte) boundary to improve performance when loading or storing stack-based SIMD values.

Register RBP is frequently used as a frame pointer that can reference data items or local storage on the stack. If a function does not require a frame pointer, RBP can be used as a general-purpose register. You will learn more about the stack and frame pointers in Chapters 11 and 12.

Instruction Pointer

The instruction pointer register RIP contains the logical address of the next instruction to be executed. The processor automatically updates the value in RIP during the execution of each instruction. RIP is also updated during execution of a control-transfer instruction. For example, the call (Call Procedure) instruction pushes the contents of RIP onto the stack before transferring program control to the specified address. The ret (Return from Procedure) instruction transfers program control by popping the top-most eight bytes off the stack and loading them into the RIP register.

The jmp (Jump) and jcc (Jump if Condition is Met) instructions also transfer program control by modifying the contents of RIP. Unlike the call and ret instructions, x86-64 jump instructions are executed independent of the stack. Register RIP is also used for displacement-based operand memory addressing as explained later in this chapter. It is not possible for an executing function to directly access the contents of register RIP.

RFLAGS Register

For application programs, the most important status bits in RFLAGS are the following flags: carry flag (RFLAGS.CF), overflow flag (RFLAGS.OF), parity flag (RFLAGS.PF), sign flag (RFLAGS.SF), and zero flag (RFLAGS.ZF). Some arithmetic instructions use the carry flag to signify an overflow condition when performing unsigned integer arithmetic. It is also used by some rotate and shift instructions. The overflow flag signals that the result of a signed integer operation is too small or too large. The processor sets the parity flag to indicate whether the least-significant byte of an arithmetic, compare, or logical operation contains an even number of “1” bits (parity bits are used by some communication protocols to detect transmission errors). The sign and zero flags are set by arithmetic and logical instructions to signify a negative, zero, or positive result.

RFLAGS contains a control bit called the direction flag (RFLAGS.DF) that is used by x86 string instructions. An application program can set or clear the direction flag, which defines the auto increment direction (0 = low to high addresses, 1 = high to low addresses) of the RDI and RSI registers during execution of a string instruction. Reserved bits in RFLAGS should never be modified, and no assumptions should ever be made regarding the state of any reserved bit.

Floating-Point and SIMD Registers

X86-64 processors that support AVX and AVX2 include 16 256-bit wide registers named YMM0–YMM15. The low-order 128 bits of each YMM register is aliased to a 128-bit wide XMM register as shown in Figure 10-4. The YMM and XMM registers can be used as operands with most AVX and AVX2 instructions to carry out either packed integer or packed floating-point operations.

The XMM register set also supports scalar floating-point operations including basic arithmetic, comparisons, and type conversions. The processor uses the low-order 32 bits of an XMM register to perform scalar single-precision floating-point operations as illustrated in Figure 10-5. Similarly, the processor uses the low-order 64 bits of an XMM register to carry out scalar double-precision floating-point operations. When performing scalar floating-point operations, the processor does not directly manipulate the high-order 96 bits (single precision) or 64 bits (double precision) of an XMM register. However, some x86-AVX scalar floating-point instructions modify these bits in a destination operand. You will learn more about this in Chapter 12.

Not shown in Figure 10-2 is the legacy x87 floating-point unit (FPU). An x86-64 program can still use the x87 FPU to perform scalar floating-point arithmetic. However, the x87 FPU is normally not used in x86-64 programs since it is more efficient code-wise to use the XMM register set to carry out scalar floating-point arithmetic.

AVX-512 extends the width of each YMM register from 256 bits to 512 bits. The 512-bit wide registers are named ZMM0–ZMM15. AVX-512 also adds 16 new SIMD registers named ZMM16–ZMM31. These new registers include aliased 256-bit wide YMM and 128-bit wide XMM registers as illustrated in Figure 10-6. Also shown in Figure 10-6 are eight opmask registers. AVX-512 instructions use these registers to perform merge masking and zero masking. The opmask registers are also employed to store the results of AVX-512 SIMD compare operations. You will learn more about the opmask registers in Chapters 17 and 18.

MXCSR Register

Application programs normally do not directly modify the floating-point exception mask bits in MXCSR. However, most C++ runtime environments provide a library function that allows an application program to designate a callback function that gets invoked whenever a floating-point exception occurs. Application programs can modify the MXCSR’s rounding control bits, and you will learn how to do this in Chapter 12.