Re: Future of ELKS

David Given
2004-05-21T16:30:45Z

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_