Is ESP as general-purpose as EAX?

Question

In the x86 architecture, what can be done with EAX but not with ESP? Forgetting about push and pop and call.

Answer 1

ESP is implicitly used asynchronously by interrupts. In modern OSes, that only applies to the kernel stack, not the user-space stack. Kernel code always needs to keep ESP valid when interrupts are enabled, and assume the space below it is clobbered after every instruction.

The main (only?) asynchronous use of ESP in user-space is signal handlers, so a process with no signal handlers shouldn't have any asynchronous use of ESP. (A kernel can even deliver signals to user-space using a stack other than the thread's current stack pointer, e.g. POSIX sigaltstack, although if nested signal handling is possible using the alt-stack, signal-handler code can't assume anything). See Is it valid to write below ESP? for a more detailed look at things on Windows, where special cases of SEH can happen anywhere, making it not safe in general to use space below ESP.

Also, debuggers may use the target process's stack when evaluating something like print foo(1) to call a function in the target program. (But otherwise are non-intrusive, under modern multi-tasking OSes.)

So user-space code can in some cases get away with using ESP as an 8th GP register in a critical loop that otherwise has to spill something, but as that article points out, it makes debugging less convenient on Windows where SEH wants to find a valid stack. Use an MMX or XMM register to save/restore ESP, because static storage wouldn't be thread-safe, and the stack isn't available (chicken/egg problem). The same argument in theory applies to using RSP in 64-bit code, but 15 regs other than RSP, and guaranteed SSE2 support, makes this extremely unlikely to be worth it.

Everything else in this answer applies equally to RSP in 64-bit mode.

---

ESP limitations as a GP register operand in asm / machine code

There's only one thing ESP can't do that every other register can: ESP can't be the index register in an addressing mode.

mov  edx, [esp + eax*4]        ; legal
mov  edx, [eax + esp*4]        ; not encodeable

mov  edx, [eax + esp]          ; assemblers will encode this with esp as the base reg, since neither reg is scaled.

If I remember correctly, this is the only case where ESP just plain isn't available as an operand. The other special case is that ESP as a base register always requires a SIB byte, even when there's no index:

mov  edx, [eax]          ; 2 bytes: opcode + ModRM
mov  edx, [ebp]          ; 3 bytes: opcode + ModRM + disp8=0  (the other addressing-mode limitation, ebp/rbp and r13 as a base reg needs a displacement; the mode+M encoding that would mean this actually mean something else)
mov  edx, [esp]          ; 3 bytes: opcode + ModRM + SIB

mov  edx, [ebp + 4]      ; 3 bytes: opcode + ModRM + disp8
mov  edx, [esp + 4]      ; 4 bytes: opcode + ModRM + SIB + disp8

mov  edx, [ebp + 4 + eax]   ; 4 bytes: opcode + ModRM + SIB + disp8
mov  edx, [esp + 4 + eax]   ; 4 bytes: opcode + ModRM + SIB + disp8

pop into ESP is also a bit special because order of operations between reading the implicit source, the implicit increment of ESP, and writing of the explicit destination matters: pop esp is like mov esp, [esp]. (Also, popa skips reloading ESP). See What is an assembly-level representation of pushl/popl %esp? for details.

---

It is also worth pointing out that there are a lot of things special about EAX, even compared to other registers like ECX. For example, it is implicitly used with stos, cdq, and as an operand for mul (and this list is not exhaustive). There is also a 1-byte encoding for xchg eax, reg (great for code golf but not performance!), and for the common ALU operation with an imm32 (like add eax, imm32 vs. add r/m32, imm32). (Look up these ALU instructions online or the original PDF of Intel's instruction reference manual—see the x86 tag wiki for links.)

The only one of the base 8 general-purpose registers that isn't "special" or used implicitly by any common instructions is EBX. For more info on x86 registers and where their names come from / traditional uses, see http://www.swansontec.com/sregisters.html