It s like a more stable version of the stack pointer

Storage for some local variables and parameters are generally allocated in stack frames that are automatically freed simply by popping the stack pointer back to its original level after a function call.

However, the stack pointer is frequently being adjusted in order to push arguments on to the stack for new call levels and at least once on entry to a method in order to allocate its own local variables. There are other more obscure reasons to adjust the stack pointer.

All of this adjusting complicates the use of offsets to get to the parameters, locals, and in some languages, intermediate lexical scopes. It is perhaps not too hard for the compiler to keep track but if the program is being debugged, then a debugger (human or program) must also keep track of the changing offset.

It is simpler, if technically an unnecessary overhead, to just allocate a register to point to the current frame. On x86 this is %ebp. On entry to a function it may have a fixed relationship to the stack pointer.

Besides debugging, this simplifies exception management and may even pay for itself by eliminating or optimizing some adjustments to the stack pointer.

You mentioned the program counter, so it s worth noting that generally the frame pointer is an entirely software construct, and not something that the hardware implements except to the extent that virtually every machine can do a register + offset addressing mode. Some machines like x86 do provide some hardware support in the form of addressing modes and macro instructions for creating and restoring frames. However, sometimes it is found that the core instructions are faster and the macro ops end up deprecated.

This isn t really a C question since it s totally dependent on the compiler.

However stack frames are a useful way to think about the current function and it s parent function. Typically a frame pointer points to a specific location on the stack (for the given stack depth) from which you can locate parameters that were passed in as well as local variables.

Here s an example, let s say you call a function which takes one argument and returns the sum of all numbers between 1 and that argument. The C code would be something like:

unsigned int x = sumOf (7);
: :
unsigned int sumOf (unsigned int n) {
    unsigned int total = 0;
    while (n > 0) {
        total += n;
        n--;
    }
    return total;
}

In order to call this function, the caller will push 7 onto the stack then call the subroutine. The function itself sets up the frame pointer and allocates space for local variables, so you may see the code:

        mov  r1,7            ; fixed value
        push r1              ; push it for subroutine
        call sumOf           ; then call
retLoc: mov  [x],r1          ; move return value to variable
: :
sumOf:  mov  fp,sp           ; Set frame pointer to known location
        sub  sp,4            ; Allocate space for total.
: :

At that point (following the sub sp,4), you have the following stack area:

      +--------+
      | n(7)   |
      +--------+
      | retLoc |
      +--------+
fp -> | total  |
      +--------+
sp -> |        |
      +--------+

and you can see that you can find passed-in parameters by using addresses above the frame pointer and local variables below the frame pointer.

The function can access the passed in value (7) by using [fp+8], the contents of memory at fp+8 (each of those cells is four bytes in this example). It can also access its own local variable (total) with [fp-0], the contents of memory at fp-0. I ve used the fp-0 nomenclature even though subtracting zero has no effect since other locals will have corresponding lower addresses like fp-4, fp-8 and so on.

As you move up and down the stack, the frame pointer also moves and it s typical that the previous frame pointer is pushed onto the stack before calling a function, to give easy recovery when leaving that function. But, whereas the stack pointer may move wildly while within a function, the frame pointer typically stays constant so you can always find your relevant variables.

Good discussion here, with examples and all.

In short: the FP points to a fixed spot within the function s frame on the stack (and does not change during function execution), so all passed-arguments and the function s local ("auto") variables can be accessed by offsets from the FP (while the SP can change during a function s execution, and the PC definitely does;-).

Usually the return address (but sometimes just past last argument, for example). The point is that the frame pointer is fixed during the life of a method while the stack pointer could move during execution.

This is very implementation dependent (and more a machine concept, not really a language concept).

Lifted from a comment you provided to another answer:

Woh... Stack Pointer?... is that synonymous to Program Counter?

Read about the call stack. Basically the call stack stores data local to a current method (local variables, parameters to the method and return address to the caller). The stack pointer points to the top of that structure which is where new space is allocated (by moving the stack pointer "higher").

The frame pointer points to an area of memory in the current frame (current local function), typically it points to the return address of the current local function.

Since no one has responded to this yet I ll give it a try. A frame pointer (if memory serves) is part of the stack along with the stack pointer. The stack is comprised of stack frames (sometimes called activation records). The stack pointer points to the top of the stack while the frame pointer typically points to some fixed point in a frame structure, such as the location of the return address. Theres a more detailed description along with a picture on wikipedia.

link text