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@xxxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
