From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: Future of ELKS Date: Fri, 21 May 2004 17:30:45 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200405211730.45239.dg@cowlark.com> References: <1084985870.3062.23.camel@talena.hsol.net> <40AD4286.1090801@cowlark.com> <20040521132425.GP24490@duckman.distro.conectiva> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20040521132425.GP24490@duckman.distro.conectiva> Content-Disposition: inline List-Id: Content-Type: text/plain; charset="us-ascii" To: linux-8086@vger.kernel.org On Friday 21 May 2004 14:24, Eduardo Pereira Habkost wrote: [...] > What I mean is: do we want and have people that could do the work > of making or porting a good compiler work on the 8086? [...] > but my question is: > the ELKS project is interested in spending efforts directed to creating a > good development environment (read: a good compiler, a 'make', linker, > > and their friends, and that makes the work of creating and porting > applications not so expensive) that runs on ELKS? Well... Minix has all this. It all works, it's all debugged, it's all open source. It all runs self-hosted on Minix with a 64/64 split address space. The only problem is that Minix' compiler, bcc, only supports K&R C. However, there are tools available that will convert ANSI C into K&R C; that's how ELKS is currently built. Admittedly, you don't get the superior type checking that ANSI C gives you, but it does build. As I see it, there are three real options here: a) Put quite a lot of effort into writing an ANSI C compiler that will run self-hosted on ELKS (and Minix). b) Give up on building anything self-hosted and cross-compile everything using gcc or Turbo C++ (which produces good code, and has been released for free by Borland: http://community.borland.com/article/0,1410,20841,00.html). c) Do both. Cross-compile with an ANSI C compiler, but build self-hosted using bcc and unprotoize. This has the advantage that we get the advanced type checking of ANSI C if we cross-compile, but the lightweight toolchain of K&R if it's built self-hosted. Interestingly enough, (c) is already what we have. It's just that nobody has really got around to setting up a self-hosted system. There's nothing technically stopping it from working, except for the occasional minor bug. (BTW, if you look at the mailing list archives, way back in the mists of time there was a six-month discussion on what compiler to use. Let's not do that again...) On Friday 21 May 2004 15:15, Jody wrote: [...] > The 8086/88's biggest limitation has to be the segmented memory model to > retain compatibility with some old CPU (8085?) and these compatibility > efforts have hindered Intel CPUs for a long time... Segmentation is also what makes ELKS work at all on the 8086. It acts as a poor-man's MMU. Without segmentation, you wouldn't be able to have relocatable processes; you wouldn't be able to do any kind of swapping or move code around at run time. (Remember that a 64/64 process is using 16-bit points for everything. It never touches its segment registers. If you copy the process onto disk, reload it elsewhere, restore its registers but make sure that the segment registers point to its new location in memory, it'll never even notice.) Yes, we *could* use some kind of larger memory model with bigger pointers, but I wouldn't recommend it. Using multiple segments makes stuff far more complicated --- particularly as ints and pointers will now be different sizes --- and any 8086 program that needs more than 128kB is probably too big anyway. If you think 128kB of RAM is too small to do anything useful, I strongly urge you to go out and look into CP/M. Your average CP/M system had about 60kB free for user applications, shared between code and data. 8080 and Z80 code is significantly more verbose than 8086 code. But look at all those applications... -- +- David Given --McQ-+ "I can handle myself. I've been in a fire fight. | dg@cowlark.com | Well, I was in a fire.... Actually I was fired. | (dg@tao-group.com) | from a fry cook opertunity." --- Firefly, _War +- www.cowlark.com --+ Stories_