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?

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.

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?

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

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.