From mboxrd@z Thu Jan 1 00:00:00 1970 From: u-vpoa@aetey.se Subject: Re: We have a whole new ton of goodies to investigate... Date: Mon, 27 Apr 2015 16:44:49 +0200 Message-ID: <20150427144449.GY8197@example.net> References: <20150426212223.GT8197@example.net> <20150427003128.0c61965e@www.etchedpixels.co.uk> <20150427070643.GV8197@example.net> <20150427115327.072762af@www.etchedpixels.co.uk> <20150427123036.GX8197@example.net> <20150427143554.7adaee70@www.etchedpixels.co.uk> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20150427143554.7adaee70@www.etchedpixels.co.uk> Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alan Cox Cc: linux-8086@vger.kernel.org On Mon, Apr 27, 2015 at 02:35:54PM +0100, Alan Cox wrote: > > One extra thing I would appreciate in the kernel is of course the support > > for code segment switching, making several-times-64k code sizes practical. > > If you are willing to accept violating the standard when comparing > function pointers, and you are willing to pull a couple of other stunts > then that is actually trivial. You generate far calls for all inter > function calls, and also tell the compiler to assume the arguments are 2 > bytes further up the stack. This implies that the compiler must be "more-than-16-bits-aware" and produce a larger code. I like the trampolines approach, when you have all pointers, including the function ones, as 16 bit, and you can use any compiler. The address of a function is the same in all segments, which is the address of its linker-generated trampoline. There is some size and run time overhead but only at inter-segment calls and at function pointer dereferencing. This needs only support in the linker and in the kernel (like "ld -m" on Venix/86). > I think the Coherent compiler can also do it "properly". It can for 286 > anyway, I've not been through the 8086 version in enough detail to figure > it out. Wonder how hard it were to port it to run under ELKS. > > this can easily push the limits both for the code and the data, if not > > putting the drivers into different address spaces or strictly limiting > > the number of simultaneously usable drivers) > > On a box with very little memory it makes little sense to include drivers > you don't need! Oh yes, but you can happen to have lots of various connected hardware _and_ many times 64K memory which would make this argument void. > If you compare it with 4BSD or System 5 on the syscall level I'd say yes. Nice! > It may well need bug fixing and structural work for size but it's only > really lacking the relatively modern syscalls, most of which are > inappropriate and the others could I guess be added but none of the small > userspaces use them - openat etc. Yes. > The networking side lacks IPv6 and a lot of other bits, but that's > outside the core, and could probably be reworked to keep the current > kernel bits pretty much as is and adopt lwip for the stack. +1 Rl