In message <507C9A02.1020300@chocky.org>
Peter Naulls <peter@chocky.org> wrote:
> Having considered this in the past, EABI binaries (and let's assume
> Linux ARM binaries for a concrete example), really assume a dynamic/
> sparse memory arrangement for stack/heap handling. This is certainly
> possible on RISC OS with probably some straightforward modifications,
> but it does mean moving away from the 20(?) year old chunked stack
> model, although you'd continue to support that for older code.
> That might be a good thing, since chunked stacks have drawbacks too.
The chunked stacks feature is probably the primary reason why APCS-32
has no future. We can perfectly have our stack in DA and page in
extra ram when the stack is growing beyond its initial allocated size.
This frees up sl and avoids costly stack limit checks on nearly every
function call.
> The bottom line is that you'd need RISC OS modifications to do this
> at all, I think. But that might end up being less intrusive than say,
> the 32-bit SCL stuff.
If you organize the stack in a DA, I'm sure you can solve this with
a module. If you want your stack in application workspace, i.e. let
it grow downwards, while the heap is growing upwards and also page in
RAM when required, yes, what will require changes in RISC OS. I'm not
sure whether the last option is a better one if you consider the
possibility of multiple threads each having its own stack.
John.
--
John Tytgat, in his comfy chair at home BASS
John.Tytgat@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment