Why the HEAP region ?

[Chris Johns]

Joel Sherrill wrote:
> 
> On Thu, 12 Jun 1997, Chris Johns wrote:
> 
> > I was wondering why a separate region is created in the libc support
> > code for the heap ?
> >
> > The bsp start code creates a region called the work space region.
> Why is
> > this region not used ?
> 
> The Work Space Area is not a region (it is implemented directly using
> the Heap Handler in the supercore) and is exclusively for use by RTEMS
> for
> object control blocks, task stacks, etc.  The amount of memory
> required
> for this can be calculated based on your configuration table and a
> couple
> of other parameters.
> 

I suppose the API tells you this when you think about it. You need an id
of a region to request memory.

> The C library/program heap is a region because that is what is user
> accessible and supports concurrent access.  The division between
> application and executive space is intentional.  Long ago there was
> talk
> about redoing the newlib heap management to use a mutex to provide
> shared
> access to a heap but right now each task must have its own heap to get
> any
> time of reentrancy in newlib.  That is the original driving factor
> behind
> the RTEMS malloc code.  Long term, we will probably use the proposed
> newlib improvements to malloc when they show up.
>

Oh, I did not know a task has a separate heap. I have read the libc code
in rtems, namely 'malloc.c'. Where do I find this code ?

Is there a limit on the heap given to each task ?

> > I would like to give all the memory after the bss section to the
> work
> > space, and have the heap get memory from there. This way I do not
> have
> > to adjust the work space when a new task is added and the stack
> required
> > cannot be allocated.
> 
> If this is all you are concerned about, there are extension hooks to
> manage the allocation of your own task stacks.  I think these hooks
> unfortunately do not pass in a requested size but I think Tony Bennett
> has
> patches for this he has not collected up yet.
>

It is not an issue at this point in time. I was more interested in the
history after looking at now to divide the memory between the heap and
the work space.
 
> > This is an even greater issue when code is downloaded to a running
> > target (I know number of tasks etc are also fixed, but that is
> another
> > issue).
> 
> This is a more fundamental issue and most certainly tougher to
> address.  I
> suppose that something could be done about it but it would require
> some
> fundamental rework of the object manager especially ids and the local
> table.
> 

Again this is not an issue at this point in time. 

Code downloading is a great feature for an embedded operating system. I
have implemented downloading on pSOS+ in the past. The major pain was
the ROM contains fixed resource settings, and a fixed size for the work
space (region 0 in pSOS).

Chris