From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jody" Subject: Re: Future of ELKS Date: Fri, 21 May 2004 02:08:59 -0400 Sender: linux-8086-owner@vger.kernel.org Message-ID: <006f01c43efa$1bedc550$0101a8c0@vash> References: <1084985870.3062.23.camel@talena.hsol.net> <40AC99A5.9030809@agora-2000.com> <1085066127.3062.35.camel@talena.hsol.net> <20040520153744.GL24490@duckman.distro.conectiva> <40AD4286.1090801@cowlark.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: Linux-8086 > People these days are used to very big computers. You don't realise just > what's possible in a small amount of space. The granddaddy of Unix > systems, the PDP11 [*], was a 64kB-64kB I/D system. Sound familiar? > That's exactly the same as what's supported by ELKS. > > As for compilers... well, I have a full ANSI C compiler that runs on > CP/M. It runs in 64kB of memory shared between code and data and it'll > generate moderately decent Z80 code. If that's possible, then a > self-hosted ANSI C compiler for ELKS is certainly possible. If the ELKS system as a whole is designed (evolved?) correctly, we will certainly see the potential for a native C compiler within it. By hacking gcc to death, I hope we will reach this more quickly... > The problem is *finding* one... compilers are expensive technology, and > there's only a few open-source compilers around. Most of them are pretty > large. ELKS' current compiler, bcc, is a well-hacked version of Minix's > compiler. It only supports K&R, with a nasty preprocessor that converts > ANSI to K&R, but it will run self-hosted on Minix so it should run on > ELKS, too. It doesn't yet, but then again, someone in here with the initiative can surely "bcc-ize" bcc (if anything I have said ever sounded like utterly crappy word chopping...that was it) but that will take a lot of work, just like the proposed gcc-8086 attempts will. > And a development environment is not that complicated. All you need is > to be able to run make, the compiler front end, and the compiler back > end, concurrently. Add in init and that makes four processes. If each > one of these uses its maximum of 128kB of memory that means it'll need > 512kB of memory. That's pushing it on a 640kB system, what with the > kernel and system workspace in there, but manageable. On a 286 with a > real MMU it's easy. Of course if we write it right, there's the likelihood that we won't eat entire segments with each process...which would be necessary for a 256K working system in my opinion. > If Minix can do it, with its slow and inefficient microkernel, ELKS can > certainly do it. > > [...] > > Hey, someone know if a 8086 is fast enough run emulators for those old > > 8-bit game consoles? 8) > > Nah. A 4.77MHz 8086 does not get a lot of work done. Say you want to > emulate a 2MHz 6502, such as the BBC Micro... this means you have about > two and a half cycles to emulate each 6502 cycle. Just not possible. Emulation and 8086 don't mix! *grin* Jody