Re: LPC900/80C51 Compiler Toolchain
- From: David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 03 Jul 2007 23:04:18 +0200
wilco.dijkstra@xxxxxxxxxxxx wrote:
On 28 Jun, 05:17, David Brown <d...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
CBFalconer wrote:wilco.dijks...@xxxxxxxxxxxx wrote:
The solution to this is to use fixed size stackframe across the wholeIMO you are designing some ugly code generators. For example,
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.
consider the addressing code need to push versus a dedicated
store. Something like one byte for the push, and three up for the
store.
It's possible to temporarily increment the stack pointer and then push
the arguments so you get the best of both worlds. This is never worse
than pushing first and later incrementing SP. Also note that on many
CPUs the first few arguments are passed by registers, so the cost of
storing stack arguments is less important in such cases.
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.
Indeed, and many RISCs don't even support push/pop.
Many RISC architectures *do* support push and pop, through register indirect with automatic pre/post increment/decrement modes, though they are not too fussed about which register is called "SP". But pipeline stalls are likely if you have several "push" or "pop" instructions in a row.
On an AVR, the push is a single instruction which is much smaller and faster
as there is no (SP + offset) mode.
Actually on AVR push has the same size and speed as the (base +
offset) addressing mode. Usually the Y or Z register is used as the
actual stack. SP only supports push/pop/call/return, so it is useless
for general parameter passing or local variables. Using a frame
pointer would be a very bad idea as it takes many instructions to set
up and uses up another 2 registers.
That all depends on whether you want to have a separate return stack and data stack, or a combined stack. There are advantages in each - a data stack (indexed by Y) gives you (Y + index) addressing modes, but effectively locks the Y register and complicates stack arrangements since every task needs two individual stacks. A combined stack avoids these issues, but requires Y to be set up as a frame pointer for functions with data on the stack (not as much of a problem as it might seem, as the AVR has plenty of registers for local data).
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.
You can always find functions where it is worse of course, but
omitting frame poiners and fixed size frames are better on average on
many CPUs. Optimization is all about improving things on average.
No, "optimisation" is about getting the best possible code (faster, smaller, or whatever other definition of "best" you are using). Look up the word in a dictionary. Thus a good optimiser will use a frame pointer or not, a fixed frame size or a variable frame size, according to the combination that generates the best code for the task in hand.
Wilco.
- Prev by Date: Re: FPGA Development Board
- Next by Date: Re: Anyone using project collaboration tool?
- Previous by thread: "Status of fuzzy logic"
- Next by thread: Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
- Index(es):
Relevant Pages
|
