因為utilfunc僅有3個實參，呼叫它不要求棧使用，因為所有的實參都適用暫存器。另外，因為它是一個葉子函式，gcc選擇對其所有區域性變數使用紅區。這樣，無需減少rsp（隨後恢復）來為這些資料分配空間。

保留基地址指標

基地址指標rbp（以及x86上它的前身ebp），作為一個函式執行期間棧幀起始的一個穩定“錨點”，對手動反彙編程式碼以及除錯都十分便利[1]。

不過，不久前，注意到編譯器生成的程式碼不是真正地需要它（編譯器很容易追蹤rsp的偏移），DWARF除錯格式提供了無需基地址指標訪問棧幀的方式（CFI）。

這是為什麼某些編譯器開始對進取的優化忽略基地址指標，因此縮短了函式的prologue與epilogue，並提供了多一個通用暫存器（記得嗎，在只有有限GPR的x86上這相當有用）。

Gcc在x86上預設保留基地址指標，但允許以-fomit-frame-pointer編譯選項進行優化。到底有多推薦使用這個選項是一個有爭議的問題——如果有興趣你可以google一下。

不管怎麼說，AMD64 ABI引入的另一個“革新”是使得基地址指標顯式可選，規定：

作為棧幀一個幀指標的%rbp的便利使用，可以通過使用%rsp（棧指標）索引棧幀來避免。這個技術在prologue與epilogue中節省了兩條指令，並使得另一個通用暫存器（%rbp）可用。

Gcc堅持這個建議，在以優化編譯上，在x64上預設忽略幀指標。通過提供-fno-omit-frame-pointer選項，給出了保留它的一個選擇。 為了清晰起見，上面顯示的棧幀的生成沒有忽略幀指標。

Windows x64 ABI

在x64上Windows實現自己與ADM64ABI稍有不同的版本。我將只是簡單地討論Windowsx64 ABI，談論它的棧幀與AMD64的如何不同。以下是主要的差別：

1.      僅4個整數/指標實參在暫存器中傳遞（rcx，rdx，r8，r9）。

2.      沒有紅區的概念。事實上，這個ABI明確宣告rsp以下區域被視為volatile，使用是不安全的。作業系統、偵錯程式或中斷處理控制代碼可能改寫這個區域。

3.      作為替代，由呼叫者在每個棧幀中提供了一個“暫存器引數區”[2]。在呼叫一個函式時，在返回地址之前，在棧上最後分配的是用於至少4個暫存器（每個8位元組）的空間。這個區域對被呼叫者可用，而無需顯式地分配它。這對可變引數函式以及除錯（提供引數已知的位置，與此同時暫存器可能重用於其他目的）是有用的。儘管這個區域最初的設想是用作濺出在暫存器中傳遞的4個引數，現在編譯器也為其他優化目的而使用它（例如，如果函式的區域性變數需要少於32位元組的棧空間，可以使用這個區域，而無需觸碰rsp）。

在Windows x64 ABI中進行的另一個重要的改變是呼叫慣例的清理。不再有cdecl/stdcall/fastcall/thiscall/register/safecall這些瘋狂的存在——只有一個“x64呼叫慣例”。為此歡呼！

關於此及Windows x64 ABI其他方面的更多資訊，下面是一些好的連結：

·        關於x64軟體約定的官方的MSDN頁面——組織良好的資料，個人認為比AMD64ABI文件更容易理解。

[1] 因為在一個函式裡，rbp總是指向前一個棧幀，它形成了棧幀的一種連結串列，在任何時候偵錯程式可以用來訪問棧執行追蹤（在core dump中也一樣）。

[2]有時也稱為“” called "home space" sometimes.