3 ms·
Right. I'm talking about this: // Make 128 byte scratch space for the Red Zone. This arithmetic will not unalign // our stack pointer because 128 is a mult
by EE84M3i 6y ago
Right. I'm talking about this:
// Make 128 byte scratch space for the Red Zone. This arithmetic will not unalign
// our stack pointer because 128 is a multiple of 16. The Red Zone must also be
// 16-byte aligned.
sp -= 128;
Isn't the red zone normally implicitly below the sp? I'm not sure why you would need to explicitly subtract the size here.
- mijoharas 6y agoEDIT - the following answer is based on an incorrect understanding of the red zone. See the reply to this for a correction. I shall leave it here as a monument to my shame. Yes, so since the stack grows downwards, we subtract the size of the red zone from the top of the stack (represented by the stack pointer), moving the new stack pointer down. This "grows" the stack (downwards remember) by the size of the red zone. Future allocations on the stack bump the pointer further downwards to grow the stack further. This leaves the 128 bytes of the red zone always below the stack. EDIT: to clarify the red zone is below the stack pointer conceptually (below the stack) but higher in memory actually (since the stack grows downwards).
- Veserv 6y agoNo. The red-zone is in the unused area beyond the current stack pointer that the stack will grow into. It moves with the current stack pointer. The author of the article is incorrect. https://stackoverflow.com/questions/38042188/where-exactly-is-the-red-zone-on-x86-64 https://stackoverflow.com/questions/38042188/where-exactly-i...
- mijoharas 6y agoOh damn, I totally misremembered, thank you for correcting me! Kinda dumb of me, because even thinking for a second about what the red zone is for would make it obvious why I'm wrong.