Re: Future of ELKS

[David Given <dg@cowlark.com>]

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_