OSDev.org

i know SP only could visit the top value of stack, BP could visit each value of stack.
many code often use BP visit stack, use SP shortly, why ?

C calling convention typically uses bp to store the last value for sp. The space between sp and bp is the local variable stack frame. They usually use bp for stack accesses since it defaults to using the SS segment instead of DS. Otherwise you'd have to use a segment override prefix.

There is no reason whatsoever at all to use ebp instead of esp in a normal 32-bit flat address space.

Actually there is - the enter and leave instructions are designed to interact between ebp and esp. It is part of the calling convention of almost all languages. And you need a pointer into the stack if you want to be able to unwind it. Hence, BP/EBP/RBP

Combuster wrote:Actually there is - the enter and leave instructions are designed to interact between ebp and esp. It is part of the calling convention of almost all languages. And you need a pointer into the stack if you want to be able to unwind it. Hence, BP/EBP/RBP

Correct in that it does make stack frames possible to unwind, but incorrect in that it is not implemented in all ABIs. MIPS doesn't have a dedicated frame pointer, and when it does (-fno-omit-frame-pointer) it doesn't point at the top (high address) of your stack frame, but at the same place where the stack pointer would normally point, the difference being that variadic increases in the stack frame (e.g. use of alloca()) changes the stack pointer and not the frame pointer.

So if you're coding for multiple architectures, it's useful to be able to unwind the stack without relying on a high-water-mark frame pointer, perhaps by the use of debugging symbols (e.g. DWARF CFI unwinding tables), and in which case, the frame pointer is no longer needed.

c.f. Linux 2.4 at least compiles with -fomit-frame-pointer.

i think the only reason is that push and pop instruction would be OK if you changed BP value.

david wrote:i think the only reason is that push and pop instruction would be OK if you changed BP value.

Exactly - the frame pointer is useful in situations where you have a dynamically sized stack frame (i.e. use of alloca). It's mainly useful for hand-crafted assembler though, or for nice backtraces. (as I mentioned earlier)

i know the default segment register is SS if you use bp.

Combuster wrote:Actually there is - the enter and leave instructions are designed to interact between ebp and esp. It is part of the calling convention of almost all languages. And you need a pointer into the stack if you want to be able to unwind it. Hence, BP/EBP/RBP

The enter and leave instructions are not necessary if you don't use EBP... There is no reason to use them if you're not using EBP as a stack frame pointer.
Why you'd want to embed debugging info (stack unwinding) in a production executable is beyond me. And as JamesM said, debugging is often better handled by proper debugging info.

Wave wrote:The enter and leave instructions are not necessary if you don't use EBP... There is no reason to use them if you're not using EBP as a stack frame pointer.

But you still want LEAVE on x86 because its faster than standard epilogue (Hey thats what AMD optimization manual says).

Wave wrote:The enter and leave instructions are not necessary if you don't use EBP... There is no reason to use them if you're not using EBP as a stack frame pointer.

Enter and leave imply the use of EBP and ESP. If you were to use EDX instead, then enter and leave become pretty pointless. Together with the automatic use of SS, this forms the reason why EBP is used rather than some random other register.

Why you'd want to embed debugging info (stack unwinding) in a production executable is beyond me.

To be able to debug errors random users give you. With the help of a stacktrace, execution log and error message other people gave me, I have over time worked out lots of problems I never thought would happen.

And as JamesM said, debugging is often better handled by proper debugging info.

Since when is a stacktrace a bad way of diagnosing problems?

Actually, a quick google revealed stack unwinding (and hence, EBP) is used for structured exception handling as well (i.e, non-debugging purposes)

edit:

JamesM wrote:... but incorrect in that it is not implemented in all ABIs. MIPS doesn't have a dedicated frame pointer

I said languages, and I doubt MIPS has a register named (E)BP.

standard epilogue

Standard epilogue includes a frame pointer change. If you didn't need that, that would be one memory access down. Memory access times are large, you what you lose by using several instructions instead of one macroinstruction you gain by having one less memory access.

Two consecutive instructions are less likely to cause a cache miss than one (heavily microcoded) instruction and one memory fetch at the top of the current stack frame.

exkor wrote:

Wave wrote:The enter and leave instructions are not necessary if you don't use EBP... There is no reason to use them if you're not using EBP as a stack frame pointer.

But you still want LEAVE on x86 because its faster than standard epilogue (Hey thats what AMD optimization manual says).

Well, the manual is wrong then. LEAVE is faster than updating EBP manually, but it's not faster than dropping EBP altogether.

Combuster wrote:

Why you'd want to embed debugging info (stack unwinding) in a production executable is beyond me.

To be able to debug errors random users give you. With the help of a stacktrace, execution log and error message other people gave me, I have over time worked out lots of problems I never thought would happen.

When they have problems, send them the debug build. Why send the debug build to everyone???

Wave wrote:When they have problems, send them the debug build. Why send the debug build to everyone???

LOL, I can see Microsoft sending a debug build to everyone experiencing a crash of say IE instead of the "report problem" button dialog.


JAL