Re: LPC900/80C51 Compiler Toolchain

CBFalconer wrote:
wilco.dijkstra@xxxxxxxxxxxx wrote:
On 27 Jun, 11:52, CBFalconer <cbfalco...@xxxxxxxxx> wrote:
wilco.dijks...@xxxxxxxxxxxx wrote:

... snip ...

Most compilers stopped using frame pointers a long time ago. They
are inefficient and don't actually provide any benefit. Rather
than changing SP repeatedly inside a function, SP is adjusted only
on entry and exit of the function, further improving efficiency.
This also makes it easier to track stack variables in debuggers
(as offsets from SP are fixed). The drawback is that stacksize can
grow in some circumstances. Functions containing alloca or C99
arrays could still use a frame pointer.
You are confused as to the use of an 'SP'. This is a stack
pointer, which is altered whenever a value is pushed or popped. It
can't be constant, so the compiler has to keep track of it. You
are probably thinking of a 'BP', or block pointer, which normally
holds specific SP values such as the value on function entry.
No. If you remove the frame pointer and don't change anything else,
you're left with a constantly changing stack pointer. This makes it
harder to access variables on the stack. For example, if the SP+offset
addressing mode has a limited offset, you may be able to use that
addressing mode only if the offset is small enough. Additionally, as
David said, most debuggers can't deal with these changing offsets
(Dwarf3 can describe this, but few debuggers support this format, let
alone the builtin interpreter that can do this stuff).

The solution to this is to use fixed size stackframe across the whole
function - ie. SP does not change. This is always possible as you can
reserve space for function arguments at fixed offsets from SP and
store them rather than push. The advantage is that you avoid having to
adjust SP to undo pushes, which further improves the saving.

Although the fixed-size frame optimization is orthogonal to removing
the frame pointer, the advantages (debugging is possible and code
usually more efficient) mean that they typically go together.

IMO you are designing some ugly code generators. For example,
consider the addressing code need to push versus a dedicated
store. Something like one byte for the push, and three up for the
store.


That's very much dependent on the cpu architecture. On some architectures, storing data at (SP + offset) takes exactly the same time and space as a push - on others, it is significantly different. On superscaler 32-bit RISC cpus it is likely that the (SP + offset) store will be faster, as a push which changes SP will lead to stalls. On an AVR, the push is a single instruction which is much smaller and faster as there is no (SP + offset) mode.

And for some types of function, trying to use a single fixed-size stack frame will make a real pig's ear out of the code, and result in lots of wasted stack space - a frame pointer really does give better code for some functions.

As with anything in this field, unless you are going to give specific and tight limits on the processors and the type of code, any generalisations like this are going to be wrong.
.

Relevant Pages

  • Re: Passing parameters & return value on the stack
    ... I was wandering if there's any way push N parameters on the stack, ... I'll have to assume 'arg_N' are the args for pusha and pushf. ... This means the 'arg_N' 'xx' offset for the pusha and pushf could be either ...
    (alt.lang.asm)
  • Re: Passing parameters & return value on the stack
    ... I was wandering if there's any way push N parameters on the stack, ... I'll have to assume 'arg_N' are the args for pusha and pushf. ... This means the 'arg_N' 'xx' offset for the pusha and pushf could be either ...
    (alt.lang.asm)
  • Re: x86 retf confusion
    ... I push a 16 bit selector and an offset onto the stack ... and issue a retf instruction, this allows me to start execution ...
    (alt.lang.asm)
  • [NEWS] Win32 Device Drivers Communication Vulnerabilities - Tutorial
    ... What is the Device Driver? ... PAGE:000164D3 push esi; esi to the stack ... PAGE:00016526 mov ecx,; ECX=signal code ... we will look at this offset later ...
    (Securiteam)
  • Re: LPC900/80C51 Compiler Toolchain
    ... Although the fixed-size frame optimization is orthogonal to removing ... storing stack arguments is less important in such cases. ... storing data at (SP + offset) takes exactly the same time ... up and uses up another 2 registers. ...
    (comp.arch.embedded)