sfp寄存器_FP寄存器及frame pointer介绍

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寄存器。

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

环境：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:

可以看到函数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:

这里把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:

优化后的版本：

$ arm-linux-objdump -D no_SFP_arm.o

no_SFP_arm.o:     file format elf32-littlearm

Disassembly of section .text:

这里，"fp"充当了"EBP"的角色，ESP在X86里面被leave隐含的恢复好了，所以没有显示设置的必要。

看起来arm平台上"-fomit-frame-pointer"选项的优化作用更加明显。