From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alfonso Martone Subject: Re: some ELKS suggestions Date: Fri, 28 Mar 2003 18:17:42 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200303281817.42589.a.martone@retepnet.it> Reply-To: a.martone@retepnet.it Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: linux-8086@vger.kernel.org > I wasn't in on the early development of ELKS, so some of these > answers are no more than educated guesses as to the history of > the features you refer to. I'm one of those who told his friends "Yay!! There's a Linux port on 8086, and it's called ELKS 0.0.44!!!" :-) But, frustrated from that extreme experimental stuff, hangs, from time to time I checked out for newer releases... > crash solid if it does. Remember that EVERY interrupt will use the > kernel stack, so it isn't easy to calculate how much is needed. 64k > happens to be as large as it can go, and that is probably the main > reason for that choice. 64k of kernel stack seems to me too much on a system with less than 512k RAM. I wrote so because I thought that the worst-case would be less than 5-6k (except system static data). > Why can't SI and DI be used for parameters, esp if the parameter is > an address? Yes, it ain't forbidden. It just requires a few bytes more for byte handling (that is: if SI happens to contain a byte variable, then it cannot be written back to memory without using an 8-bit register: SI isn't splittable in SH/SL like AH/AL...). There is another issue: parameter-passing via stack (even calling an interrupt) may be better than using registers. The INT 0x80 interface of ELKS kernel just works with the stack because kernel functions are written in C. This may suggest even to use a stack-based (instead of register-based) INT 0x80 interface...! (would save a number of bytes in the kernel and in the executables). > > the kernel? ELKS kernel has already str[n]cpy, atoi, str[n]cat, > You'd need to deal with far data and swapping. It gets horrible. Far data handling is needed only if DS/SS were updated to the kernel stack: but the strcpy, sprintf, etc can just run using "userland" segment-registers because they don't require kernel level features. Yes, dealing with swapping would be really horrible. > > - you can stay in little (little, little, little) RAM; > Its not clear how much you win, plus systems like UZI and OMU aready > exist in C and are tons smaller than Linux Uh... I come from Ye Olde Anciente Times, when men were men and wrote their own operating systems in full assembler source "burn-optimizing" even the latest byte. Of those times I regret only self-modifying code and excessive paranoid tricks (extreme clock cycle calculations etc). alf