[gccsdk] Using Dynamic Areas
John.Tytgat at aaug.net
Sat Jul 19 09:23:58 PDT 2008
In message <7cbd66c14f.admin at snowstone.org.uk>
Adam <lists at snowstone.org.uk> wrote:
> In message <467a5dc14f.Jo at hobbes.bass-software.com>, John Tytgat wrote:
> > We had an older suggestion to actually change the default (when
> > appname$heap is not set) based on whether we're running on RISC OS 5
> > or not (i.e. whether the WimpSlot size is limited to 28 MByte or not)
> > as this is probably the biggest reason to explicitly set it.
> I think the current behaviour is good as it's consistent across
But what good is that if the platforms themselves are not consistent ?
This is not meant as a finger pointing to RISC OS 5 for going for large
WimpSlots but rather as an argument to have the default UnixLib choice
for its memory allocation suitably made.
> I've not really paid any attention to the differences between the
> wimpslot and dynamic areas up until now as I've never needed to worry
> about a large-footprint app before...
It is only relevant for large programs and/or large data sets.
> > > Looking at the Usage file and the UnixLib header files, I think I
> > > need to do:
> > >
> > > #include <unixlib/features.h>
> > #include <features.h>, no ?
> Thanks. (That line was derived from the example in the Usage file.)
Really ? At one point in the docs we had "#include <unixlib/features.h>"
but that got changed in r1775 in Nov 2005. Could it be that you're looking
at such old docs ?
> > No I don't think so. I think just a little bit more documentation is
> > needed. I *think* you just need to add:
> > const char *__program_name = "BayTrader";
> That complains about conflicting declarations, but using "const char *
> const" (as per the line in features.h) works and produces a dynamic area
Yes true. And that was because we wanted to express a large hint that
you may not change __program_name at runtime.
> P.S. I've just been playing around with AppName$HeapMax and noticed that
> if you set it to a small value, the initial dynamic area is restricted to
> that size, but then a series of 1MB areas, called "<AppName> MMap" get
> created. What's the significance of this?
When you create a DA, you better give a reasonable maximum size and it's
that amount of memory which gets reserved for your DA (not necessary filled
with RAM at that point). If you specify large sizes, your available DA area
in the 4 GByte memory map gets quickly filled up as those DA areas are
permanently allocated and don't get swapped in or out during task swapping
(the API is forseen but AFAIK not implemented). When UnixLib runs out
of given max DA size, it will create up to 8 other DA's with the same
limit. That's what you see as "xxx MMap".
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc