From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georg Potthast 2 Subject: Re: Elks networking Date: Tue, 31 Jan 2017 11:32:48 +0100 (CET) Message-ID: <990587541.474117.1485858768986@com4.strato.de> References: <20170130215909.0653a2ed@www.etchedpixels.co.uk> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1485858770; l=1981; s=domk; d=georgpotthast.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:To:From:Date; bh=0q+rgtmMhRE/O/e9HczjmAuKq4HutkTgPm3gaObBOFw=; b=vfjAo+puGvv1HlXNt2Z36Iw3WYOAQuUd0Ifv5tSeZe00BwxEdfDWaXot/XV9g9f5mx wcxhThao249YUzEMpYwM44HacWJ8Ul59Q0oSrtF3lEw/qYYWPDEzLqxn+p3Jw6PbkLqv u2BVYK0SFo+A5pywyFHMxx0kWjJij8Goi0CDM= In-Reply-To: <20170130215909.0653a2ed@www.etchedpixels.co.uk> Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Linux-8086@vger.kernel.org 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 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.