Re: Future of ELKS

[Eduardo Pereira Habkost <ehabkost@conectiva.com.br>]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On Fri, May 21, 2004 at 12:43:02AM +0100, David Given wrote:
> Eduardo Pereira Habkost wrote:
> [...]
> >1. Create a good development environment that runs on elks (we don't
> >   have it). This environment will have all limitations that the 8086
> >   hardware will impose to us
> >2. Make elks build using it
> >
> >IMHO, this would be almost impossible.
> 
> Well... no!
> 
> 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.
> 
> 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.
> 

Okay, that is not *really* impossible. Not technically impossible.
The question is: we have people that can do it?

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?

As you said: compilers are expensive, or in other words: this require
lots of work. The question is: we have enough people that would do this
work? Technically, this *is* possible, you are right, 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? This environment could
be the better we can do for the 8086, but it could have limitations
that the "bloated" tools (*hint* GNU *hint*) don't have (yes, yes,
I know someone can make a "perfect" system that do wonderful things,
but we still don't have it). I would like to know if we want this.

> 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.

What I mean by "development environment", is what I said above: a good
compiler a 'make' or similar tool, a linker, and their friends. It is not
so complicated, but someone should code it. Do we have people that can
do this? If someone wants to do it, he is very welcome. But do we want
to spend efforts doing this? Will it be worth? I don't know. For me it
is not worth, just because I don't want to run a compiler on my 8086,
but someone could really want it, who knows?

Anyway, if we want to take this way, someone should work on that
development environment, or the project would stop again.

> 
> 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.

Ohh, sad. I should forget it.

> 
> 
> [*] Or maybe the PDP7. I always get the two confused.
> 

-- 
Eduardo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]