some Elks suggestions

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

> 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