OS: Does the stack always grow in upward direction or it is system dependent ?

Question

It is very basic query but clearing the doubt always make your knowledge stronger.

Answer 1

The behavior of stack (growing up or growing down) depends on the application binary interface (ABI) and how the call stack (aka activation record) is organized.
The stack for different architectures can grow the either way, but for an architecture it will be consistent.
But, the stack's growth is decided by the ABI of that architecture.
So, if the variables are allocated to the local frame of the function, the variable's addresses actually grows downward. The compiler can decide on the order of variables for memory allocation. (In your case it can be either 'q' or 's' that is first allocated stack memory. But, generally the compiler does stack memory allocation as per the order of the declaration of the variables).

But in case of the arrays, the allocation has only single pointer and the memory needs to be allocated will be actually pointed by a single pointer. The memory needs to be contiguous for an array. So, though stack grows downward, for arrays the stack grows up.
source-http://stackoverflow.com/questions/1677415/does-stack-grow-upward-or-downward

Answer 2

Stack grows downwards. That's why it is called stack. And heap grows upwards, That's why it is called heap.

However, th eMSP has a hardware stack that is initialized to a certain ram position (usually the top of ram) and grows downward on every call or push operation and upwards again on every pop and ret instruction.
The MSP430 has no way to limit growing down into the heap or the global variables. It may also shrink above its start when you pop more form the stack than you pushed onto it. But that's a serious coding error then.

Global variables are defined at compiletime and (usually) placed at beginning of ram at linktime.

The heap is the free area between the topmost global variable and the (current) bottom of the stack. The heap is managed by software at runtime. In theory, you can allocate as much heapspace as there is between top of global vars and bottom of stack. However, the stack won't care if it then grows into already allocated heapspace, causing havoc to your stored data (and storing data on the allocated heapspace will corrupt the stack too).

For this reason, you can set a heapsize value. The heap management software (malloc/free functions etc.) will then not allocate more than this amount.
You can also set a stacksize value. This will ensure that at linktime there will be enough room for all global variables, the defined heapspace and at least the defined tack space. However, this setting cannot know how large the stack will really grow. And local variables are placed on stack too.
We had a case where someone was declarign a local arra that was larger than the total ram of the MSP. THis pushed the stack instantly below ram area with devastating results. However, there was no compiler or linker warning. The compiler didn't know about maximum ram and the linker doesn't know about local variables.

On CPUs with a memory management unit (the MSP has none), you can set thresholds which cause an interrupt when the stack grows beyond a set size or when the applicaiton write to or reeads from memory that is outside the assigned space area. However, if this happens, teh applicaiton is already dead and all that can be done is killing it isntantly and returnign to OS (and the MSP has none).