From: u-vpoa@aetey.se
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-8086@vger.kernel.org
Subject: Re: We have a whole new ton of goodies to investigate...
Date: Mon, 27 Apr 2015 16:44:49 +0200 [thread overview]
Message-ID: <20150427144449.GY8197@example.net> (raw)
In-Reply-To: <20150427143554.7adaee70@www.etchedpixels.co.uk>
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
next prev parent reply other threads:[~2015-04-27 14:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-26 21:22 We have a whole new ton of goodies to investigate u-vpoa
2015-04-26 23:31 ` Alan Cox
2015-04-27 7:06 ` u-vpoa
2015-04-27 10:53 ` Alan Cox
2015-04-27 12:30 ` u-vpoa
2015-04-27 13:35 ` Alan Cox
2015-04-27 14:44 ` u-vpoa [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-04-16 11:14 LM
2015-04-16 11:39 ` Alan Cox
2015-04-03 20:40 Alan Cox
2015-04-15 17:10 ` MFLD
2015-04-15 21:41 ` Alan Cox
2015-04-16 7:35 ` MFLD
2015-04-16 11:49 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150427144449.GY8197@example.net \
--to=u-vpoa@aetey.se \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).