This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why do stacks typically grow downwards?
Every architecture I have seen, stack is growing in the way that pushed value is given lower memory address. Is there any reason for that?
The lowest addresses are always reserved for special registers. Picking the lowest ensures that no matter the version of the micro (variable amounts of ram), the special registers are always in the same place.
By starting the stack at the very top, you only need to know one thing. The top address.
It sort of decouples two separate design issues. Reserved register placement and stack origin.
Related
This question already has answers here:
How exactly does the callstack work?
(7 answers)
Closed 3 days ago.
A stack overflow error occurs when a program tries to use more memory in the stack that has been allocated to the stack. But I heard that the stack can grow up or down. If it can grow when it needs memory, then how do stack overflow errors occur?
Does this mean that heap overflow errors exist?
Typically an application has a set maximum amount of stack space. The stack can grow up to that maximum. When the application is started, the operating system allocates a small amount of space for its stack. As needs warrant, the operating system can allocate more space for the application's stack. But it can't ever go beyond the maximum.
So why not just let it grow, unbounded? Because no computer has infinite memory. If we placed no restriction on the amount of stack space an application can use, then a misbehaving application would run until it allocated all the memory available. It wouldn't take long to effectively lock up the machine, preventing any work from being done.
So we place limits on stack space. The default is more than enough for most programs. If you determine that your application needs more than the default stack space, then you can specify a larger stack at build time.
I came accross an option in the Delphi 6 IDE:
How does changing the memory stack sizes here affect the IDE? If I increase this value would there be more memory available for the IDE?
No, stack size does not influence on IDE work.
This is linker option, it defines how much stack size will be available for your compiled program. At most max stack size.
Stack is used to hold local variables and sometimes function arguments. You seldom need to increase stack sizes if application design is quite good. Stack overflow (if happens) might be a result of unlimited recursion due to logical mistakes or result of defining too large local variables (for example - static arrays)
P.S. What problem are you going to solve?
The title pretty much says it. I am writing an algorithm (and right now porting it into nasm) that would need to allocate lots (upwards of 8gb) of ram (as a severe tradeoff for cpu usage). On every iteration it stores an int onto the stack (for output and later usage). Then, periodically it could free a set of values but only from the bottom of the stack. Could this be done by simply decrementing the stack base (rbp)?
A stack is a stack. You can push and pop values on the top but nothing more. You cannot deallocate anything from it in any other way.
Changing RBP doesn't do anything, it is just a helper register to use for the current stack frame. RSP shows the current top of the stack and moving that changes where the next value will be stored to or retrieved from within the stack. So you can drop a bunch of values from the top if needed, but not from the bottom.
If you have a need to temporarily store values and later release them then a circular buffer or blocks of regular memory would be a much better suited for that.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What and where are the stack and heap
My installation of Ubuntu has a default stack size limit of 8 MB. But I am curious as to why we need to restrict a user program's stack size. The same program can use all of its 4 GB (for a 32 bit program) addressable space via malloc/mmap etc. So why do we need a stack size limit? Why can't the stack grow till it almost meets the heap?
In fact the stack does grow more and more. It doesn't need to start very big since in the general case, it doesn't need to be very big. Having it as very big results in a wasteful memory footprint.
I'm not 100% sure as to how the stack is implemented on Linux but on Windows, a large amount of space is reserved for the stack. This amount can be set in compiler options (you may want a larger stack for deeply recursive programs). At runtime, the stack can be extended dynamically via a guard page system. At the end of the stack there is a guard page which when hit will extend the stack by an extra page and push the guard page forward by one.
Stack probing is another interesting and related concept. So your question of 'why can't the stack grow till it almost meets the heap?' The stack does grow but since most of the time having a huge stack is likely an undesired side-effect of a bug, the reserved size will not be huge (although this is settable).
This article is very interesting and relevant to your question.
Some systems such as Symbian insist people to use heap instead of stack when allocating
big objects(such as pathnames, which may be more than 512 bytes). Is there any specific reason for this?
Generally the stack on an embedded device is fixed to be quite small i.e. 8K is the default stack size on Symbian.
If you consider a maximum length filename is 256bytes, but double that for unicode that's 512bytes already (1/16th of your whole stack) just for 1 filename. So you can imagine that it is quite easy to use up the stack if you're not careful.
Most Symbian devices do come with an MMU, but, until very recently, do not support paging. This means that physical RAM is committed for every running process. Each thread on Symbian has (usually) a fixed 8KB stack. If each thread has a stack, then increasing the size of this stack from 8KB to, say 32KB, would have a large impact on the memory requirements of the device.
The heap is global. Increasing its size, if you need to do so, has far less impact. So, on Symbian, the stack is for small data items only - allocate larger ones from the heap.
Embedded devices often have a fixed-sized stack. Since a subroutine call in C only needs to push a few words onto the stack, a few hundred byte may suffice (if you avoid recursive function calls).
Most embedded devices doesn't come with a memory management unit so there is no way for the OS to grow the stack space automatically, transparent to the programmer. Even assuming a growable stack, you will have to manage it yourself which is no better than heap allocation and defeats the purpose of using a stack in the first place.
The stack for embedded devices usually resides in a very small amount of high-speed memory. If you allocate large objects on the stack on such a device, you might be facing a stack overflow.