{"id":107077,"date":"2022-08-31T07:00:00","date_gmt":"2022-08-31T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107077"},"modified":"2022-09-10T06:29:54","modified_gmt":"2022-09-10T13:29:54","slug":"20220831-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220831-00\/?p=107077","title":{"rendered":"The x86-64 processor (aka amd64, x64): Whirlwind tour"},"content":{"rendered":"

I figure I’d tidy up the processor overview series by covering the last\u00b9 processor on my list of “processors Windows has supported in its history,” namely, the x86-64. Other names for this architecture are amd64 (because AMD invented it) and x64 (which is super-confusing because it doesn’t correspond with x86, a common nickname for the x86-32).<\/p>\n

This is going to be a quick overview because the x86-64 is a natural extension of the i386, which we covered some time ago<\/a>. I’ll just highlight the differences.<\/p>\n

Each existing 32-bit general-purpose register has been extended from 32 bits to 64. The name of the 64-bit register is based on the name of the 32-bit register, but with the leading e<\/var> changed to a leading r<\/var>. Eight new 64-bit registers were introduced, bring the total to 16. Instead of giving quirky names to the new registers, they are just numbered: r8<\/var> through r15<\/var>. To match the existing classic registers, the new registers also have aliases for referring to partial registers, and partial register aliases were invented for some of the classic registers that lacked them.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Register<\/th>\nAliases<\/th>\nPreserved?<\/th>\nNotes<\/th>\n<\/tr>\n
Bits 31:0<\/th>\nBits 15:0<\/th>\nBits 15:8<\/th>\nBits 7:0<\/th>\n<\/tr>\n
rax<\/var><\/td>\neax<\/var><\/td>\nax<\/var><\/td>\nah<\/var><\/td>\nal<\/var><\/td>\nNo<\/td>\nReturn value<\/td>\n<\/tr>\n
rbx<\/var><\/td>\nebx<\/var><\/td>\nbx<\/var><\/td>\nbh<\/var><\/td>\nbl<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
rcx<\/var><\/td>\necx<\/var><\/td>\ncx<\/var><\/td>\nch<\/var><\/td>\ncl<\/var><\/td>\nNo<\/td>\nParameter 1<\/td>\n<\/tr>\n
rdx<\/var><\/td>\nedx<\/var><\/td>\ndx<\/var><\/td>\ndh<\/var><\/td>\ndl<\/var><\/td>\nNo<\/td>\nParameter 2<\/td>\n<\/tr>\n
rsi<\/var><\/td>\nesi<\/var><\/td>\nsi<\/var><\/td>\n <\/td>\nsil<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
rdi<\/var><\/td>\nedi<\/var><\/td>\ndi<\/var><\/td>\n <\/td>\ndil<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
rsp<\/var><\/td>\nesp<\/var><\/td>\nsp<\/var><\/td>\n <\/td>\nspl<\/var><\/td>\nYes<\/td>\nStack pointer<\/td>\n<\/tr>\n
rbp<\/var><\/td>\nebp<\/var><\/td>\nbp<\/var><\/td>\n <\/td>\nbpl<\/var><\/td>\nYes<\/td>\nFrame pointer<\/td>\n<\/tr>\n
r8<\/var><\/td>\nr8d<\/var><\/td>\nr8w<\/var><\/td>\n <\/td>\nr8b<\/var><\/td>\nNo<\/td>\nParameter 3<\/td>\n<\/tr>\n
r9<\/var><\/td>\nr9d<\/var><\/td>\nr9w<\/var><\/td>\n <\/td>\nr9b<\/var><\/td>\nNo<\/td>\nParameter 4<\/td>\n<\/tr>\n
r10<\/var><\/td>\nr10d<\/var><\/td>\nr10w<\/var><\/td>\n <\/td>\nr10b<\/var><\/td>\nNo<\/td>\n <\/td>\n<\/tr>\n
r11<\/var><\/td>\nr11d<\/var><\/td>\nr11w<\/var><\/td>\n <\/td>\nr11b<\/var><\/td>\nNo<\/td>\n <\/td>\n<\/tr>\n
r12<\/var><\/td>\nr12d<\/var><\/td>\nr12w<\/var><\/td>\n <\/td>\nr12b<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
r13<\/var><\/td>\nr13d<\/var><\/var><\/td>\nr13w<\/var><\/td>\n <\/td>\nr13b<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
r14<\/var><\/td>\nr14d<\/var><\/td>\nr14w<\/var><\/td>\n <\/td>\nr14b<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
r15<\/var><\/td>\nr15d<\/var><\/td>\nr15w<\/var><\/td>\n <\/td>\nr15b<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The eip<\/var> and eflags<\/var> registers are correspondingly expanded to 64-bit registers rip<\/var> and rflags<\/var>.<\/p>\n

Additional restrictions have been imposed on the use of the ah<\/var>, bh<\/var>, ch<\/var>, and dh<\/var> registers. The details aren’t important for reading code, so I won’t bother digging into them.<\/p>\n

Windows requires that the stack be 16-byte aligned at function call boundaries, and there is no red zone. Calling a function pushes the 8-byte return address onto the stack, so on entry to a function, the stack is misaligned. Functions typically realign the stack in their prologue.<\/p>\n

The old 8087-based floating point registers are not used.\u00b2 Instead, the SIMD XMM registers are used for floating point calculations. These registers are 128 bits wide and can be viewed as four single-precision floating point values or as two double-precision floating point values. When used to pass parameters or return floating point values, only the bottom lane is used.<\/p>\n

Eight more XMM registers have been added, bringing the total to 16.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Register<\/th>\nPreserved?<\/th>\nNotes<\/th>\n<\/tr>\n
XMM0<\/var><\/td>\nNo<\/td>\nParameter 1 and return value<\/td>\n<\/tr>\n
XMM1<\/var><\/td>\nNo<\/td>\nParameter 2 and second return value<\/td>\n<\/tr>\n
XMM2<\/var><\/td>\nNo<\/td>\nParameter 3<\/td>\n<\/tr>\n
XMM3<\/var><\/td>\nNo<\/td>\nParameter 4<\/td>\n<\/tr>\n
XMM4<\/var><\/td>\nNo<\/td>\n <\/td>\n<\/tr>\n
XMM5<\/var><\/td>\nNo<\/td>\n <\/td>\n<\/tr>\n
XMM6<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM7<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM8<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM9<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM10<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM11<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM12<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM13<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM14<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n
XMM15<\/var><\/td>\nYes<\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Calling convention<\/b><\/p>\n

The calling convention is register-based for the first four parameters, with remaining parameters on the stack. In practice, the stack-based parameters are not push<\/code>‘d, but rather the values are mov<\/code>‘d into the preallocated stack space.<\/p>\n

For register-based parameters, integer parameters go into the general-purpose registers and floating point parameters go into the floating point registers. When a register is used to hold a parameter, its counterpart register goes unused. For example, a function that takes an integer and a double will pass the integer in rcx<\/var> and the double in xmm1<\/var>.<\/p>\n

There are always 4 \u00d7 8 = 32 bytes of home space for the register-based parameters, even if the function has fewer than four formal parameters. (If this bothers you, then you can reinterpret the home space as a 32-byte red zone that resides above<\/var> the return address.)<\/p>\n

Integer return values up to 64 bits go into rax<\/var> If the return value is a 128-bit value, then the rdx<\/var> register holds the upper 64 bits. Floating point return values are returned in xmm0<\/var>.<\/p>\n

The caller is responsible for cleaning the stack. In practice, the caller does not clean the stack after every call, but rather preallocates the stack space in the prologue, reuses the stack space for multiple calls, and then cleans it all up in the epilogue.<\/p>\n

Exception handling is done by unwind tables, not by threading exception handlers through the stack at runtime.<\/p>\n

Partial registers<\/b><\/p>\n

When a 32-bit partial register is the destination of an operation, the upper 32 bits are set to zero. For example, consider<\/p>\n

    add     eax, ecx\r\n<\/pre>\n
On the 32-bit 80386, this adds the value of ecx<\/var> to eax<\/var> and puts the result back into eax<\/var>. On x86-64, this performs the same calculation, but since the destination is the 32-bit partial register eax<\/var>, the operation also zeroes out the upper 32 bits of rax<\/var>.<\/p>\n
Another way of looking at this is that writes to 32-bit partial registers are zero-extended<\/var> to 64-bit values.\u00b3<\/p>\n
Note, however, that operations on 16-bit and 8-bit partial registers leave the unused bits unchanged.<\/p>\n
Addressing modes<\/b><\/p>\n
The 32-bit addressing modes carry over to 64-bit, with these exceptions:<\/p>\n