1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Difference Between Stack Pointer and Frame Pointer

Discussion in 'Embedded' started by ravikumar.n, Jul 1, 2005.

  1. ravikumar.n

    ravikumar.n Guest

    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
     
    ravikumar.n, Jul 1, 2005
    #1
    1. Advertisements

  2. ravikumar.n

    Mike Silva Guest

    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
     
    Mike Silva, Jul 1, 2005
    #2
    1. Advertisements

  3. ravikumar.n

    Dave Hansen Guest

    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
     
    Dave Hansen, Jul 1, 2005
    #3
  4. ravikumar.n

    Lanarcam Guest

    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
     
    Lanarcam, Jul 1, 2005
    #4
  5. 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.
     
    Everett M. Greene, Jul 3, 2005
    #5
  6. ravikumar.n

    toby Guest

    Care to name a counterexample?
     
    toby, Jul 4, 2005
    #6
  7. ravikumar.n

    toby Guest

    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 | <- 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
     
    toby, Jul 4, 2005
    #7
  8. ravikumar.n

    Dave Hansen Guest

    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
     
    Dave Hansen, Jul 5, 2005
    #8
  9. ravikumar.n

    Richard Guest

    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, Jul 5, 2005
    #9
  10. clues?

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

    Meindert
     
    Meindert Sprang, Jul 5, 2005
    #10
  11. ravikumar.n

    Dave Hansen Guest

    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
     
    Dave Hansen, Jul 5, 2005
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.