理解过程来自以下URL：
http://eli.thegreenplace.net/2011/02/04/where-the-top-of-the-stack-is-on-x86/
和另一个地址，忘了。。。
C代码：
int foobar(int a, int b, int c)
{
int xx = a + 2;
int yy = b + 3;
int zz = c + 4;
int sum = xx + yy + zz;
return xx * yy * zz + sum;
}
int main()
{
return foobar(77, 88, 99);
}
STACK FRAME,栈帧结构图示，以EBP作定位：
MASM汇码代码对比：
_foobar:
; ebp must be preserved across calls. Since
; this function modifies it, it must be
; saved.
;
push ebp
; From now on, ebp points to the current stack
; frame of the function
;
mov ebp, esp
; Make space on the stack for local variables
;
sub esp, 16
; eax <-- a. eax += 2. then store eax in xx
;
mov eax, DWORD PTR [ebp+8]
add eax, 2
mov DWORD PTR [ebp-4], eax
; eax <-- b. eax += 3. then store eax in yy
;
mov eax, DWORD PTR [ebp+12]
add eax, 3
mov DWORD PTR [ebp-8], eax
; eax <-- c. eax += 4. then store eax in zz
;
mov eax, DWORD PTR [ebp+16]
add eax, 4
mov DWORD PTR [ebp-12], eax
; add xx + yy + zz and store it in sum
;
mov eax, DWORD PTR [ebp-8]
mov edx, DWORD PTR [ebp-4]
lea eax, [edx+eax]
add eax, DWORD PTR [ebp-12]
mov DWORD PTR [ebp-16], eax
; Compute final result into eax, which
; stays there until return
;
mov eax, DWORD PTR [ebp-4]
imul eax, DWORD PTR [ebp-8]
imul eax, DWORD PTR [ebp-12]
add eax, DWORD PTR [ebp-16]
; The leave instruction here is equivalent to:
;
; mov esp, ebp
; pop ebp
;
; Which cleans the allocated locals and restores
; ebp.
;
leave
ret
而64位的架构为了提高性能速度，作FUNCTION CALL时将6个变量直接放在寄存器，而非通过内存。
而且，在STACK FRAME下方有128BYTE的REDZONE。呵呵，作啥用的没有深研，反正RETURN时会被清空回收。。。
理解来自同一作者：
Argument passing
I’m going to simplify the discussion here on purpose and focus on integer/pointer arguments [3]. According to the ABI, the first 6 integer or pointer arguments to a function are passed in registers. The first is placed in rdi, the second in rsi, the third in rdx, and then rcx, r8 and r9. Only the 7th argument and onwards are passed on the stack.
long myfunc(long a, long b, long c, long d,
long e, long f, long g, long h)
{
long xx = a * b * c * d * e * f * g * h;
long yy = a + b + c + d + e + f + g + h;
long zz = utilfunc(xx, yy, xx % yy);
return zz + 20;
}
This is the stack frame:
long utilfunc(long a, long b, long c)
{
long xx = a + 2;
long yy = b + 3;
long zz = c + 4;
long sum = xx + yy + zz;
return xx * yy * zz + sum;
}
This is indeed a leaf function. Let’s see how its stack frame looks when compiled with gcc:
关于红色128个BYTE的区域，没有细看，下次有时间再看吧。
列出解释：
The red zone
First I’ll quote the formal definition from the AMD64 ABI:
The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use this area for temporary data that is not needed across function calls. In particular, leaf functions may use this area for their entire stack frame, rather than adjusting the stack pointer in the prologue and epilogue. This area is known as the red zone.
Put simply, the red zone is an optimization. Code can assume that the 128 bytes below rsp will not be asynchronously clobbered by signals or interrupt handlers, and thus can use it for scratch data, without explicitly moving the stack pointer. The last sentence is where the optimization lays – decrementing rsp and restoring it are two instructions that can be saved when using the red zone for data.
However, keep in mind that the red zone will be clobbered by function calls, so it’s usually most useful in leaf functions (functions that call no other functions).
