Why the HEAP region ?
cjohns at awa.com.au
Thu Jun 12 15:13:28 UTC 1997
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
> object control blocks, task stacks, etc. The amount of memory
> for this can be calculated based on your configuration table and a
> 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
> about redoing the newlib heap management to use a mutex to provide
> access to a heap but right now each task must have its own heap to get
> time of reentrancy in newlib. That is the original driving factor
> 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
> > space, and have the heap get memory from there. This way I do not
> > to adjust the work space when a new task is added and the stack
> > 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
> 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
> > 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
> fundamental rework of the object manager especially ids and the local
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).
More information about the users