Simon Wood writes:
> 
> Hi, 
> I'm afraid I'm not understanding this.....
> 
> I know that the code sized is fixed when an application is compiled, as is
> the initialised and un-initilised data.
> This gives us minimum code and data segment sizes.
> 
> We also need a stack, and maybe some heap space:-
>       Where does this go and how is it allocated?
>       If it is allocated at 'load' can it be resized (automatically or
> manually)?
>       Is there any checking on the Stack Size (to prevent it over writing
> the stack)?
> 
> Psion (on SIBO) seem to place a fixed stack at the bottom of the data
> segment (which grows down towards DS:0000), then initialised data, then
> un-initilised and then heap (which grows up). This has the advantage that
> the 'hardware protection' can detect if the application writes outside it's
> allocated data segment and halt the application. But the disadvantage that
> the maximum stack size MUST be allocated at compile time.
> 
> Could this approach be taken with ELKS or do we need a resizable stack?
> 

The current model is:

The data and bss ( initialised and unitialised data ) sizes are fixed at
compile time. In addition the linker places a value in the chmem field of
the header which is the estimated maximum total ammount of memory the
program will require at run time (data + bss + heap + stack). This chmem
value is the ammount that is allocated at load time. The initialised data
is loaded into this area, and then space is left for the bss, and the heap
is placed above the bss. At the very top of the data segment the arguments
and environment data from the execing process are copied, and the stack
starts just below this. The stack and heap now grow towards each other.

A scheme with a fixed stack and a heap which can grow indefinitly without
reserving the space at load time would probably be useful but I don't know
how easy it is to predict the maximum stack size for a process.

The fixed size stack would probably be best placed just above the bss with
the heap above that. This would not require any mods to the linker or
binary format, just changes to the kernel.

Al

Reply via email to