Difference Between Stack Pointer and Frame Pointer

Started by July 1, 2005
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

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.

http://www.cs.purdue.edu/homes/hosking/502/spim/node23.html

On 1 Jul 2005 06:16:15 -0700, ravikumar.n@sunlux-india.com wrote:

> >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.
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.
> > A) Please let me know what is the difference between these two >pointers.
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).
> > B) When "SP" comes into picture and when "FP" comes into picture.
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, -Úve -- Change is inevitable, progress is not.

ravikumar.n@sunlux-india.com wrote:
> 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.
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
ravikumar.n@sunlux-india.com writes:
> 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.
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.

Dave Hansen wrote:
> On 1 Jul 2005 06:16:15 -0700, ravikumar.n@sunlux-india.com wrote: > > > > >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. > > 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.
Care to name a counterexample?
> > > > > A) Please let me know what is the difference between these two > >pointers. > > 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). > > > > > B) When "SP" comes into picture and when "FP" comes into picture. > > 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, > > -Úve > -- > Change is inevitable, progress is not.
Mike Silva wrote:
> ... 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 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.
> 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. ... > http://www.cs.purdue.edu/homes/hosking/502/spim/node23.html
Here's how I diagram the conventional PDP-11 stack layout. | | higher addresses +---------------+ | argN | | ... | | arg0 | <- FP+4 +---------------+ | link reg | <- FP+2 = SP after JSR +===============+ | saved FP | <- FP after prologue +---------------+ / | locals | <- FP-2 framesize \ | ... | +---------------+ | saved regs | | ... | <- SP after prologue +---------------+ | | lower addresses Note that local function arguments are at positive offsets from FP, local variables are at negative offsets. Also note that the frame pointer itself is among the callee-saved registers. See here for a survey of subroutine linkage conventions: http://www.cs.clemson.edu/~mark/subroutines.html http://www.cs.clemson.edu/~mark/subroutines/pdp11.html (PDP-11 specific) and here http://cm.bell-labs.com/cm/cs/who/dmr/clcs.html (original PDP-11 C) --Toby
On 4 Jul 2005 00:53:06 -0700, "toby" <toby@telegraphics.com.au> wrote:

> > >Dave Hansen wrote:
[...]
>> 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. > >Care to name a counterexample?
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, -Úve -- Change is inevitable, progress is not.
> Most AVR compilers have a data stack separate from the hardware stack.

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.

http://www.FreeRTOS.org



"Richard" <nospam@thanks.com> wrote in message
news:z4xye.63232$G8.55959@text.news.blueyonder.co.uk...
> > Most AVR compilers have a data stack separate from the hardware stack. > > 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? Speed. the Imagecraft compiler keeps the hardware stack in internal RAM and the data stack in external ram when available. Meindert
On Tue, 05 Jul 2005 14:47:59 GMT, "Richard" <nospam@thanks.com> wrote:

>> Most AVR compilers have a data stack separate from the hardware stack. > >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?
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, -Úve -- Change is inevitable, progress is not.
"Richard" <nospam@thanks.com> wrote in message
news:z4xye.63232$G8.55959@text.news.blueyonder.co.uk...
> > Most AVR compilers have a data stack separate from the hardware stack. > > 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? Speed. the Imagecraft compiler keeps the hardware stack in internal RAM and the data stack in external ram when available. Meindert
> Most AVR compilers have a data stack separate from the hardware stack.

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.

http://www.FreeRTOS.org



On 4 Jul 2005 00:53:06 -0700, "toby" <toby@telegraphics.com.au> wrote:

> > >Dave Hansen wrote:
[...]
>> 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. > >Care to name a counterexample?
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, -Úve -- Change is inevitable, progress is not.
Mike Silva wrote:
> ... 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 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.
> 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. ... > http://www.cs.purdue.edu/homes/hosking/502/spim/node23.html
Here's how I diagram the conventional PDP-11 stack layout. | | higher addresses +---------------+ | argN | | ... | | arg0 | <- FP+4 +---------------+ | link reg | <- FP+2 = SP after JSR +===============+ | saved FP | <- FP after prologue +---------------+ / | locals | <- FP-2 framesize \ | ... | +---------------+ | saved regs | | ... | <- SP after prologue +---------------+ | | lower addresses Note that local function arguments are at positive offsets from FP, local variables are at negative offsets. Also note that the frame pointer itself is among the callee-saved registers. See here for a survey of subroutine linkage conventions: http://www.cs.clemson.edu/~mark/subroutines.html http://www.cs.clemson.edu/~mark/subroutines/pdp11.html (PDP-11 specific) and here http://cm.bell-labs.com/cm/cs/who/dmr/clcs.html (original PDP-11 C) --Toby

Dave Hansen wrote:
> On 1 Jul 2005 06:16:15 -0700, ravikumar.n@sunlux-india.com wrote: > > > > >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. > > 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.
Care to name a counterexample?
> > > > > A) Please let me know what is the difference between these two > >pointers. > > 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). > > > > > B) When "SP" comes into picture and when "FP" comes into picture. > > 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, > > -Úve > -- > Change is inevitable, progress is not.
ravikumar.n@sunlux-india.com writes:
> 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.
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.

ravikumar.n@sunlux-india.com wrote:
> 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.
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
On 1 Jul 2005 06:16:15 -0700, ravikumar.n@sunlux-india.com wrote:

> >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.
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.
> > A) Please let me know what is the difference between these two >pointers.
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).
> > B) When "SP" comes into picture and when "FP" comes into picture.
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, -Úve -- Change is inevitable, progress is not.
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.

http://www.cs.purdue.edu/homes/hosking/502/spim/node23.html