Re: some ELKS suggestions

Re: some ELKS suggestions

[Alfonso Martone]

> 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

some Elks suggestions

[Alfonso]

> 564 bytes is 1% of the size of the program. Thats a big deal. Neat
> stuff

Uh, does this mean that after other 99 suggestions like that, ELKS will 
disappear? =:-)


> Would you like to sent out a patch in stead of the code? :)

Er... I'm not (yet) good with things like CVS, patch, rcs, etc.
And the patch is bigger than replacing the irq.s file...!


Some time ago I found in Linux sources that to get a decent I/O wait on 
PC-type hardware one can just issue an OUT on a non-existent port (out 
0x80,al -- that is: 0xe6/0x80), instead of the classic "jmp $+2" 
(0xeb/0x00) repeated sequences. I always used it in my programs 
without pain. Maybe in elks/i86/286pmode/main.c it could be better 
than the experimental sequences of 0xeb/0x00...

Uh-oh. I'm looking at ELKS sources: IMHO it's a mess (big mess). I'm 
working a lot to get an ELKS kernel compiled without floppydisk, 
keyboard, screen drivers, etc. On my homepages I show an image of a 
single board computer (SBCC) developed by some ham radio people here 
in Italy during mid-90's, featuring an i80c186/16Mhz (with internal 
timers and interrupts logic), 16 to 128k EPROM, 32 to 768k RAM, one or 
two double-channel interrupt-driveable Zilog Z8530 (that's up to four 
serial channels), one i8255 parallel port (that is, three 8-bit I/O 
ports):  http://www.alfonsomartone.itb.it/rrbyzo.html

I have on this nice toy 128k EPROM and 192k RAM, and -for now- four 
serial channels and eight LED on one of the 8255 ports. I think that 
the EPROM could contain an ELKS kernel and a (no-writeable) boot-disk. 
It does need only the memory handling functions, read-only filesystem 
support, ktcp, etc.

So, this is my quick wish-list (don't take it too seriously, I write 
here just for fun):

1)  ELKS architecture should contain a "Plain" mode, which ignores 
everything PC-related (and even any check for Sibo, PC, MCA, etc);

2)  the SBCC card of above doesn't have any screen or keyboard or BIOS 
or things "PC"-related; maybe it can have a parallel driver for an 
2x16 Hitachi-compatible LCD screen and a parallel (polling) driver for 
a keyboard or PS/2 mouse, but this is not yet done;

3)  I don't understand why the kernel stack has to be 64k-sized. Aren't 
8k quite much? (that's more than 4,000 pushes on the stack! did anyone 
get ever a stackfull system hang?) Or, maybe, 12k? 16k? 20k? Also, 
it's not that nice loading the kernel file at 1000:0000 so that it 
starts at 1002:0000... wouldn't be nicer loading at 0FFE:0000 so that 
it starts at 1000:0000? :-)

4)  I don't understand why we should use only INT 0x80. Using 128 
vectors (from 0xff downto 0x80) or even more (if BIOS is not needed, 
we could use almost all interrupt vectors) would save a register (!!!) 
meaning that a syscall could use AX/BX/CX/DX (four parameters) instead 
of AX=syscall and BX/CX/DX (three parameters); the syscall number is 
not needed on return, so AX can still contain the return value of the 
syscall; also, we would gain a bit of extra size/speed because the AX 
register is easier to fill.
[oh, well: this was true also for Linux... at least when it didn't have 
hundreds of syscalls]

5)  (this one means "I may seem drunk"): did anyone ever thought that a 
number of classic library functions could be included in the kernel? 
ELKS kernel has already str[n]cpy, atoi, str[n]cat, str[n]cmp, etc in 
its source: add also a decent [s]printf and you will save lots (?) of 
bytes on every final executable. Yes, the main goal for every version 
is "reduce code size", but... what about reducing codesize for a bunch 
of executables? (will the dynamic-linking of C libraries save space 
and speed and work more than this weird solution?)

6)  (this one means "I'm really drunk"): did anyone ever thought about 
rewriting (from scratch!) the ELKS kernel in (almost) full assembler 
source?
- write down the specifics for a minimal set of Linux-style syscalls
- convert it to "ELKS style" (INT 0x80-0xff using AX/BX/CX/DX)
- write down a hand-optimized assembler source, then debug and enjoy..!
Why?
- you can stay in little (little, little, little) RAM;
- surely old hardware won't ever need upgrading drivers...
- more speed on "non-disk-hungry" applications;
- no more optimizing here and there in a "convert from C to ASM" style;
- sources won't be (ehm...) huge as latest Linux 2.5 release...

alf

Re: some Elks suggestions

[Alan Cox]

On Fri, 2003-02-28 at 08:44, Alfonso wrote:
> Uh-oh. I'm looking at ELKS sources: IMHO it's a mess (big mess). I'm

No offence taken, its kind of wandered and never really had a chief
evil dictator to lord over it

> 1)  ELKS architecture should contain a "Plain" mode, which ignores 
> everything PC-related (and even any check for Sibo, PC, MCA, etc);

Mainstream linux nowdays (2.5.x) actually has mach-pc mach-pc9800
mach-voyager etc..

> 3)  I don't understand why the kernel stack has to be 64k-sized. Aren't 

The kernel stack is a lot smaller than that. We have one stack per
process however. Don't be fooled by the segment ranges, the kernel 
just has SS=DS for the same range.

> 4)  I don't understand why we should use only INT 0x80. Using 128 

Because Linux did, because Minix did. 

> 5)  (this one means "I may seem drunk"): did anyone ever thought that a 
> number of classic library functions could be included in the kernel? 
> ELKS kernel has already str[n]cpy, atoi, str[n]cat, str[n]cmp, etc in 
> its source: add also a decent [s]printf and you will save lots (?) of 
> bytes on every final executable. Yes, the main goal for every version 
> is "reduce code size", but... what about reducing codesize for a bunch 
> of executables? (will the dynamic-linking of C libraries save space 
> and speed and work more than this weird solution?)

You'd need to deal with far data and swapping. It gets 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

The biggest thing Linux 8086 needs right now imho (other than someone to
act as a full time dedicated maintainer) is the block layer being ripped
out. Right now we run a full Linux block layer designed to handle tons
of clever stuff that simply isnt valid on a system without megabytes of
cache and fancy I/O cards. That block layer costs a ton of space.

Alan

Re: some Elks suggestions

[Patrick Finnegan]

On Fri, 28 Feb 2003, Alfonso wrote:

> 4)  I don't understand why we should use only INT 0x80. Using 128
> vectors (from 0xff downto 0x80) or even more (if BIOS is not needed,
> we could use almost all interrupt vectors) would save a register (!!!)
> meaning that a syscall could use AX/BX/CX/DX (four parameters) instead
> of AX=syscall and BX/CX/DX (three parameters); the syscall number is

Why can't SI and DI be used for parameters, esp if the parameter is an
address?

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu