Re: Elks networking

[Georg Potthast 2 <nospam@georgpotthast.de>]

There is a remark in the file documentation/text/memory:

"When the linker (ld) creates a binary it gives a default setting for chmem
(see writebin.c in the ld source). If you know that a particular program
uses little or no heap, you can patch bytes 24..27 in the executable to a
lower value: dseg+bseg+desired stack size."

So currently the stack is usually way too big. Usually a stack of 2k would be more than sufficient. This should be the default "desired stack size".

One could save a lot of memory if the loader would not just use the stack size ld86 has put into the executable header as its default, this means a data/stack segment of 64k, but to use the spezified bss size and a stack size of 2k instead. 

So I recommend to modify the loader to use just 2k as the stack size limit (a configurable option). Should this turn out to be insufficient for a program it will terminate with "stack overflow" and one could reconfigure this limit. With currently available programs for ELKS I do not think this will happen though.

Georg




> Alan Cox <alan@lxorguk.ukuu.org.uk> hat am 30. Januar 2017 um 22:59 geschrieben:
> 
> 2. The commercial 8086 Unix platforms actually didn't preallocate memory
> or do chmem like hacks. Instead each process got allocated two chunks of
> memory. CS pointed to the code one (which may be shared) and the code
> runs from CS:0000 to CS:whatever. The clever bit is that the data segment
> stretches from DS:0000 to DS:brk and stack from DS:sp to DS:FFFF. That
> means each data/stack segment is always 64K long. However rather than
> waste that memory the memory allocator actually interleaved processes -
> that is the space between DS:brk and DS:sp of one process might be the
> code or data of another.
> 
> This means they could always grow by swapping out/moving another task when
> either the brk/sbrk() grew memory or the compiler assisted stack pointer
> checking called the kernel to grow the stack.