Joe Dupre wrote:
>  Are there docs for this?  Suggested reading?

Try the sticky thread at the top of this forum 
(http://embdev.net/topic/129986) especially "Building bare-metal ARM 
with GNU" and the ”Insider’s Guides”.


> But how is the "free" memory used in between?  When I poke in there I
> see huge areas of unused memory with data apparently randomly scattered
> about.  There is nothing "stack-like" about it.  How does that work?

That is the 'heap'. It is used by malloc() and related functions, and in 
C++ by the 'new' operator. (So long as you have a correctly implemented 
sbrk stub that is).

>
> Is this something common to all computing systems, or does every
> compiler/processor family have it's own way of dealing with memory?

Pretty much typical, although on architectures where stacks grow up 
rather than down the heap and the stack would be swapped. Also in a 
multithreaded environment, each thread will have its own stack. A thread 
stack may be statically allocated or allocated at run-time from the 
heap. Moreover on systems that use a memory management unit, it possible 
to map the stack(s) and the heap to different protected memory segments, 
or even use virtual-memory.


Clifford

Joe Dupre wrote:
> I'd like to learn more about how "stack"/"free" memory is used in an
> ARM/GCC enviroment.  Are there docs for this?  Suggested reading?

You could browse through the ARM techlib. It explains some backgrounds. 
Most/all examples are for the Realview tools but the concepts are the 
same for all toolsets. The stack is handled by the controller.

> It is evident that the linker script defines text, data and bss area
> from the bottom up.  And it's typical that the ARM mode stack areas are
> stored at the top end end of RAM.

Hmm, maybe "typical" but basically you can place the stacks everywhere 
in RAM where it does not overlap memory that is used for .data, .bss or 
heap. The controller just needs to know where the stacks start. The 
start-addresses are what you usually "tell the controller" in the 
startup-code.

> But how is the "free" memory used in between?

In a memory layout where the stack is located at the top of the RAM the 
free space between end of linker-assigned RAM-locations (.data/.bss) and 
top of stack can be used as heap. The heap grows from a low address (the 
symbol _end is mostly used to define this address in the linker-script) 
to a higher address. If there is not enough RAM stack and heap will 
collide.

Another approach is to place the stacks at the lower end of the RAM by 
using a fixed "stack size" and placing the heap's start after all 
stacks. When using this approach you should see a core-exception when 
too much heap or stack is requested since invalid memory-locations are 
accessed. This might be easier to debug by using at least endless loops 
as exceptions handlers, attaching to the target with a debugger and 
looking in which loop/exception-handler the controller hangs and the 
value of the LR.

> When I poke in there I
> see huge areas of unused memory with data apparently randomly scattered
> about.

Usually only those parts of the RAM used for .data and .bss are 
initialized during startup. The remaining RAM is not initialized and 
after power-up the contents is undefined.

> There is nothing "stack-like" about it.  How does that work?

Until the RAM gets used by the stack it has it's reset-value (undef 
after power-up) so there is nothing "stack-like" that can be seen from 
looking at the content. The stack grows and shrinks depending while the 
applications is running so a memory-cell that has been used by function 
A can later be used by function B.

You can initialize the RAM which might be used for stacks with a fixed 
value during startup. This is a method ofter used to determine the 
maximum stack-requirement of an application (fill with fixed pattern 
during startup, look for fixed pattern after the application has been 
run for some time).

> Is this something common to all computing systems, or does every
> compiler/processor family have it's own way of dealing with memory?

I think this as rather common. Maybe beside of the fact the i.e. an 
ARM7TDMI has several stacks but usually "the stack" is the one used for 
the application's run-mode (not the ones for the excepetions). But I 
don't know enough about "all computing systems" to give a good answer.