Re: some ELKS suggestions

[Alfonso Martone <a.martone@retepnet.it>]

> 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