STACK GRO UPWARD OR DOWNWARD

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).

Jens-Michael Gross said:

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

NO! That statement is incorrect! It may just be bad wording, but even in that case, it is confusing and counter-productive to someone reading it. Besides, as natural language goes, a physical stack of things growing downward doesn't make any sense.

The "heap" and "stack" terminology have nothing to do with growth direction. "Heap" is meant to convey the image of a pile of memory you can "grab whatever you need from wherever's most convenient/efficient" and put it back later.

A stack invokes the analogy of a stack of books. You can only (easily) grab things off the top of it (pop/deallocate) and put more stuff directly on top (push/ allocate automatic).

A stack can grow up or down and can technically be located anywhere in memory, depending on the system. Memory from heap and stack are allocated in fundamentally different ways and serve different purposes.

Note that this stack analogy only really applies to allocation/deallocation, as you generally have random access to any stack variable within the active scope -- usually the MSP430 system achieves this in assembly language through indexed addressing relative to the stack pointer (SP register).

http://processors.wiki.ti.com/index.php/Code_Generation_Tools_FAQ#Q:_What.27s_the_difference_between_HEAP_and_STACK.3F

Dmitriy Chenchykov said:

A stack can grow up or down and can technically be located anywhere in memory, depending on the system.

Why did you ask if you know THE Answer? Note that this is msp430 forum so, answer is: on msp430 stack grows down towards lower addresses because SP is decremented on PUSH.

Up and down are normally associated with gravity. Stack and heap of a computer/controller have nothing to do with gravity. But their names imply a pile of similar things held together by gravity.

When you want to put away something you put it on top of the stack. Thus stack grows upward.

When you want something you do not have, you borrow it from the top of the heap. Thus heap diminishes downward.

Growing upward and diminishing downward are the two sides of the same coin. But these are just metaphors. How memories are allocated and used by stack and heap is a totally different story. They can be implemented in the same direction or different directions. (And which direction is up which direction is down?)

old_cow_yellow said:

Up and down are normally associated with gravity.

However, I've seen hardware stack implementations. The PICs (at least the smaller ones) have one. Not part of the address range at all.
Historically, a stack is a LIFO buffer (last in, first out). forth was using it for math operations.
The German word (no longer used for years now) for a stack can be translated as 'cellar storage'. Because it was growing down.

Now C (or rather, the implementation of C compilers for systems where this is possible) has messed it up by allowing random access on the stack, putting parameters and local variables on it that can be randomly accessed.

The main difference indeed (and the key element of my previous post) is, that the stack grows as the program flows. Nothing keeps it form growing, and if you don't take care when designing your software, it will grow into regions where it does harm. Either vacant memory or otherwise used memory. Stack can be manipulated by software, but is also directly used and altered by hardware (CPU instructions like PUSH and POP and CALL and RET, or by interrupts)

The heap, on the other side, has a fixed size (at least on IAR and CCS, but IIRC not on MSPGCC, where it can grow up until it smacks the current stack bottom) and a management for used and unused space on it. if the heap is full, you'll get a runtime error when you try to reserve more space. The heap is totally done in software and the MSP hardware does not know anything about its existence or usage.

old_cow_yellow said:

Up and down are normally associated with gravity. Stack and heap of a computer/controller have nothing to do with gravity. But their names imply a pile of similar things held together by gravity.

When you want to put away something you put it on top of the stack. Thus stack grows upward.

When you want something you do not have, you borrow it from the top of the heap. Thus heap diminishes downward.

Thanks, I see how the metaphor can be interpreted in more than one way.

Ilmars said:

Why did you ask if you know THE Answer? Note that this is msp430 forum so, answer is: on msp430 stack grows down towards lower addresses because SP is decremented on PUSH.

I am not the OP. I came here looking for an answer to "Which way does stack grow on MSP430?", which both you and Jens-Michael answered. I was commenting on a single sentence  in Jens-Michael's otherwise helpful answer.

Before giving the answer, Jens-Michael stated that a stack can only grow down (which is not true -- it is system dependent) and a heap can only grow upward (I don't generally see a heap as something that grows and shrinks, I think of it as borrowing and giving back, but like cow_yellow said, that's a personal interpretation thing).

Also, IMO, that statement implied that the biggest fundamental difference between stack and heap is this idea of "growth direction", which isn't true either. Heap and stack are called different things because they are fundamentally different concepts, nothing to do with growth direction on a specific platform. A "stack" that happens to grow upward does not somehow become a heap - it is still a stack, but now happens to grow upward.

In retrospect, maybe I was too "emotional" about it with the big no and the exclamation point, but this is an engineering forum on the internet. We get over it. Clearly Jens-Michael understood what I was saying and addressed it in the previous post, adding more interesting info to boot (I did not know that about the PIC stack), so this whole discussion only made the topic more helpful to whoever finds it later.

Dmitriy Chenchykov said:

Before giving the answer, Jens-Michael stated that a stack can only grow down (which is not true -- it is system dependent)

Dmitriy Chenchykov said:

(I don't generally see a heap as something that grows and shrinks

Dmitriy Chenchykov said:

Also, IMO, that statement implied that the biggest fundamental difference between stack and heap is this idea of "growth direction", which isn't true either.

The fundamental (and we all know how weak fundaments are built there days) difference is that the stack grows and shrinks serially while elements are added to or removed from it. last in, first out.
Whiel the heap is a general managed storage space where space can be allocated anywhere and released in any order (as long as there are unused regions large enough to fulfill the request).
So yes, changing the direction of growth doesn't turn a stack into a heap.

Dmitriy Chenchykov said:

this whole discussion only made the topic more helpful to whoever finds it later.