理論上來說，ARM的15個通用寄存器是通用的，但實際上并非如此，特別是在過程調用的過程中。 PCS(Procedure Call Standard for Arm architecture)就定義了過程調用中，寄存器的特殊用途。
Role in the procedure call standard r15 PC The Program Counter. r14 LR The Link Register. r13 SP The Stack Pointer. r12 IP The Intra-Procedure-call scratch register. （可簡單的認為暫存SP）
實際上，還有一個r11是optional的，被稱為FP，即frame pointer。
1，stack frame stack我們都知道，每一個進程都有自己的棧。考慮進程執行時發生函數調用的場景，母函數和子函數使用的是同一個棧，在通常的情況下，我們并不需要區分母函數和子函數分別使用了棧的哪個部分。但是，當我們需要在執行過程中對函數調用進行backtrace的時候，這一信息就很重要了。 簡單的說，stack frame就是一個函數所使用的stack的一部分，所有函數的stack frame串起來就組成了一個完整的棧。stack frame的兩個邊界分別由FP和SP來限定。
2，backtrace 在程序執行過程中（通常是發生了某種意外情況而需要進行調試），通過SP和FP所限定的stack frame，就可以得到母函數的SP和FP，從而得到母函數的stack frame（PC，LR，SP，FP會在函數調用的第一時間壓棧），以此追溯，即可得到所有函數的調用順序。
3，gcc關于stack frame的優化選項 看起來FP只是在backtrace的時候有用，所以如果我們沒有backstrace的需求，我們是否可以不使用FP。 其實gcc就有一個關于stack frame的優化選項： -fomit-frame-pointer ================================================================================= Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro "FRAME_POINTER_REQUIRED" controls whether a target machine supports this flag.

==================================================================================

這里引用別人關于這一參數的實驗，自己就不做了。

從實驗可以看出，優化后的差別是相當明顯的。當然，具體能帶來多大的性能提升，不好界定。

另外，x86中EBP寄存器相當于ARM中的FP寄存器。

==================================================================================

http://blog.csdn.net/byzs/article/details/2220461

環境：X86+Redhat 9.0，gcc 3.2.2

源文件如下：

$ cat test.c?
void a(unsigned long a, unsigned int b)
{
??????? unsigned long i;
??????? unsigned int j;

??????? i = a;
??????? j = b;

??????? i++;

??????? j += 2;

}

默認編譯選項：
$ gcc -c test.c -o with_SFP.o

反匯編后是這個樣子：
$ objdump -D with_SFP.o

with_SFP.o:???? file format elf32-i386

Disassembly of section .text:

00000000 <a>:
?? 0:?? 55????????????????????? push?? %ebp
?? 1:?? 89 e5?????????????????? mov??? %esp,%ebp
?? 3:?? 83 ec 08??????????????? sub??? $0x8,%esp
?? 6:?? 8b 45 08??????????????? mov??? 0x8(%ebp),%eax
?? 9:?? 89 45 fc??????????????? mov??? %eax,0xfffffffc(%ebp)
?? c:?? 8b 45 0c??????????????? mov??? 0xc(%ebp),%eax
?? f:?? 89 45 f8??????????????? mov??? %eax,0xfffffff8(%ebp)
? 12:?? 8d 45 fc??????????????? lea??? 0xfffffffc(%ebp),%eax
? 15:?? ff 00?????????????????? incl?? (%eax)
? 17:?? 8d 45 f8??????????????? lea??? 0xfffffff8(%ebp),%eax
? 1a:?? 83 00 02??????????????? addl?? $0x2,(%eax)
? 1d:?? c9????????????????????? leave??
? 1e:?? c3????????????????????? ret????
Disassembly of section .data:

可以看到函數ENTER時首先把上一層函數的EBP入棧，設置本函數的EBP，然后會根據臨時變量的數量和對齊要求去設置ESP，也就產生了函數的stack frame。
我們再看看函數的返回："leave"指令相當于"mov %ebp,%esp;pop %ebp",也就是ENTER是兩條指令的恢復過程，所以，后面的"ret"指令和"call"指令對應。
這里backtrace就可以根據現有函數EBP指針得知上一個函數的EBP----棧底再往上保存著上一個函數的EBP和EIP，然后就可以得知函數調用的路徑。

SFP是可以在編譯時候優化掉的，用"-fomit-frame-pointer"選項

編譯：
$ gcc -fomit-frame-pointer -c test.c -o no_SFP.o

$ objdump -D no_SFP.o

no_SFP.o:???? file format elf32-i386

Disassembly of section .text:

00000000 <a>:
?? 0:?? 83 ec 08??????????????? sub??? $0x8,%esp
?? 3:?? 8b 44 24 0c???????????? mov??? 0xc(%esp,1),%eax
?? 7:?? 89 44 24 04???????????? mov??? %eax,0x4(%esp,1)
?? b:?? 8b 44 24 10???????????? mov??? 0x10(%esp,1),%eax
?? f:?? 89 04 24??????????????? mov??? %eax,(%esp,1)
? 12:?? 8d 44 24 04???????????? lea??? 0x4(%esp,1),%eax
? 16:?? ff 00?????????????????? incl?? (%eax)
? 18:?? 89 e0?????????????????? mov??? %esp,%eax
? 1a:?? 83 00 02??????????????? addl?? $0x2,(%eax)
? 1d:?? 83 c4 08??????????????? add??? $0x8,%esp
? 20:?? c3????????????????????? ret????
Disassembly of section .data:

這里把EBP省掉了，ESP兼職了EBP的部分工作（索引臨時變量）。
顯而易見，代碼難懂了;-P， 代碼執行長度縮短了，應該能引起效率的提升。 可惡的是，不能用backtrace調試了。

看一下arm下面的情況：
含有SFP的版本：
$ arm-linux-objdump -D SFP_arm.o

SFP_arm.o :???? file format elf32-littlearm

Disassembly of section .text:

00000000 <a>:
?? 0:?? e1a0c00d??????? mov???? ip, sp
?? 4:?? e92dd800??????? stmdb?? sp!, {fp, ip, lr, pc}
?? 8:?? e24cb004??????? sub???? fp, ip, #4????? ; 0x4
?? c:?? e24dd010??????? sub???? sp, sp, #16???? ; 0x10
? 10:?? e50b0010??????? str???? r0, [fp, -#16]
? 14:?? e50b1014??????? str???? r1, [fp, -#20]
? 18:?? e51b3010??????? ldr???? r3, [fp, -#16]
? 1c:?? e50b3018??????? str???? r3, [fp, -#24]
? 20:?? e51b3014??????? ldr???? r3, [fp, -#20]
? 24:?? e50b301c??????? str???? r3, [fp, -#28]
? 28:?? e51b3018??????? ldr???? r3, [fp, -#24]
? 2c:?? e2833001??????? add???? r3, r3, #1????? ; 0x1
? 30:?? e50b3018??????? str???? r3, [fp, -#24]
? 34:?? e51b301c??????? ldr???? r3, [fp, -#28]
? 38:?? e2833002??????? add???? r3, r3, #2????? ; 0x2
? 3c:?? e50b301c??????? str???? r3, [fp, -#28]
? 40:?? e91ba800??????? ldmdb?? fp, {fp, sp, pc}
Disassembly of section .data:

優化后的版本：
$ arm-linux-objdump -D no_SFP_arm.o

no_SFP_arm.o:???? file format elf32-littlearm

Disassembly of section .text:

00000000 <a>:
?? 0:?? e24dd010??????? sub???? sp, sp, #16???? ; 0x10
?? 4:?? e58d000c??????? str???? r0, [sp, #12]
?? 8:?? e58d1008??????? str???? r1, [sp, #8]
?? c:?? e59d300c??????? ldr???? r3, [sp, #12]
? 10:?? e58d3004??????? str???? r3, [sp, #4]
? 14:?? e59d3008??????? ldr???? r3, [sp, #8]
? 18:?? e58d3000??????? str???? r3, [sp]
? 1c:?? e59d3004??????? ldr???? r3, [sp, #4]
? 20:?? e2833001??????? add???? r3, r3, #1????? ; 0x1
? 24:?? e58d3004??????? str???? r3, [sp, #4]
? 28:?? e59d3000??????? ldr???? r3, [sp]
? 2c:?? e2833002??????? add???? r3, r3, #2????? ; 0x2
? 30:?? e58d3000??????? str???? r3, [sp]
? 34:?? e28dd010??????? add???? sp, sp, #16???? ; 0x10
? 38:?? e1a0f00e??????? mov???? pc, lr
Disassembly of section .data:

這里，"fp"充當了"EBP"的角色，ESP在X86里面被leave隱含的恢復好了，所以沒有顯示設置的必要。
看起來arm平臺上"-fomit-frame-pointer"選項的優化作用更加明顯。?

總結

以上是生活随笔為你收集整理的FP寄存器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。