Difference Between Stack Pointer and Frame Pointer

Hi all, I am Ravi Kumar.N. My query is as follows:

I have heard that two types of pointers are used to operate on a stack 1) Stack Pointer 2) Frame Pointer.

A) Please let me know what is the difference between these two pointers.

B) When "SP" comes into picture and when "FP" comes into picture.

With Regards, Ravi Kumar.N

Reply to
ravikumar.n
Loading thread data ...

Since nobody else has yet responded, I'll give it a try. The way I understand it, the SP always points to the next available stack address (may need to be pre-decremented or pre-incremented first), which will be used for either pushing data or storing a return address. The SP can change while the called function is executing, if for example the function dynamically allocates a block of storage on the stack. Thus data in the stack frame such as passed parameters and local variables cannot reliably be referenced through offsets from the SP, since the SP is not guaranteed to have the same value throughout the execution of the function.

The FP, OTOH, is guaranteed to have the same value throughout the execution of the function, so all local data can be accessed via hard-coded offsets from the FP. The FP is set to a fixed value within the stack frame, often just past the last passed argument.

Here is an image I found that may be useful. You can see that offsets from FP will always be correct, but offsets from SP will depend on the size of the dynamic area and thus cannot be hard-coded.

formatting link

Reply to
Mike Silva

No. The stack pointer operates on the stack. The frame pointer operates on the frame. Very often, the frame is located in the stack, but it ain't necessarily so.

The stack pointer always points to the top (or bottom, if you prefer) of the stack. The frame pointer always points to the frame. Stack operations (e.g., push, pop, call) do not modify the frame (in a properly operating system) or the frame pointer (ever).

The SP comes into the picture when you are mainpulating the stack. The FP comes into the picture when you are manipulating the frame.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

If you want a concrete idea, consider a function call in the good old asm 68k

---------- func(a, b); move a, -(a7) ; push a on the stack, a7 move b, -(a7) ; push b jsr func ; push return adress on the stack ; and jump to func

---------- int func(int a, int b) link a6,#-8 ; push content of a6 on the stack, move a7 ; into a6. a6 is now the frame pointer ; of the called function func. decrement a7 ; by 8 to allocate storage for a and b ; a6 is the frame pointer and is used to ; reference local variables ; a7 is the stack pointer and is used to ; store return addresses for later function ; calls ... unlk a6 ; undo link: copy a6 into a7, retrieve old ; a6 from the stack rts ; pop return address from the stack

with this method a6 is the frame pointer and a7 the stack pointer.

a7 (SP) ->

a b a6 (FP) -> old a6 return address

Reply to
Lanarcam

The other replies haven't distinguished between the two pointers all that well, so I'll have a try.

The stack pointer (SP) is a hardware feature of almost all present-day processors. At a minimum, the SP points to the present end of a queue which holds return addresses of all the calls made to the moment. When a call is made, the return address is pushed onto the stack; upon exiting the called function, the return address is popped from the stack.

The frame pointer (FP) is an optional programming feature used by some programming languages on some processors. Not all processors have the hardware resources to implement a frame pointer and some implementations don't want to have the extra overhead of maintaining a frame pointer.

An FP, if used, points to a fixed point in the "user" stack and points to a location in the stack where the arguments and local variables for a called function are located. This pointer is established upon entry to a function and remains constant throughout the execution of the called function. Thus, values can be pushed onto the user stack and popped from it within the function without impacting the offsets from the FP.

Note that the user stack need not be the same queue as the one used by the hardware for return addresses. Quite often the two queues are one and the same, but there's nothing that says they have to be.

Reply to
Everett M. Greene

Care to name a counterexample?

Reply to
toby

The same is usually true of the stack pointer, the most common exception being while outgoing arguments are being stacked before a call. Once anything is pushed onto the stack, all SP-relative local frame offsets change. It's much more convenient for compilers in particular to use an FP with unchanging offsets.

Here's how I diagram the conventional PDP-11 stack layout.

| | higher addresses +---------------+ | argN | | ... | | arg0 |

Reply to
toby

[...]

Most AVR compilers have a data stack separate from the hardware stack. In this case it's on "a" stack, but not "the" stack.

Most 8051 compilers keep call frames completely separate from any stack. However, functions that use this calling convention are not reentrant.

I've heard rumors about (but have no experience with) architectures like IBM's AS/400 that allocate call frames from the heap. The reasons for this have to do with security, integrity, and fault-tolerance.

I expect there are more.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

I'm interested in this statement. The IAR compiler is the only AVR compiler I have come across that does this, and I've never been sure why. Any clues?

Richard.

formatting link

Reply to
Richard

compiler

clues?

Speed. the Imagecraft compiler keeps the hardware stack in internal RAM and the data stack in external ram when available.

Meindert

Reply to
Meindert Sprang

How many AVR compilers have you seen? The only one that _doesn't_ (AFAIK) is avr-gcc.

The primary reason it that direct manipulation of the hardware stack pointer (SP) in the AVR is non-atomic (eight bits at a time, and interrupts must be disabled on writes to prevent ISRs from stomping all over memory), while the data stack pointer can be kept in a 16-bit general purpose register that supports 16-bit math.

IOW, it makes code generation simpler, and the resulting code is both faster an smaller.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.