From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alfonso Subject: some Elks suggestions Date: Fri, 28 Feb 2003 09:44:15 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200302252028.03782.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 > 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