> 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.
Yes
> We also need a stack, and maybe some heap space:-
> Where does this go and how is it allocated?
Linux 8086 takes a very simple approach. It uses the minix (and PC/IX) trick
of setting the maximum heap size at startup time. Thats not vital, you could
put the stack at the base of the data segment and allow the BSS to grow
upwards (still a fixed stack limit). You would then need to call the kernel
for a BSS extend (sbrk - already exists notionally) and may need to shuffle
big chunks of memory around to find a new place for it.
Thats probably a better model than the current minix one.
> 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
Psion were a bit more clued up here than Minix
> 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.
That goes anyway
> Could this approach be taken with ELKS or do we need a resizable stack?
This would be a big improvement for ELKS, but one you would want to make
soon if we do it because it means recompiling the entirity of user space
and tweaking the linker.
