From: "Jody" <jbruchon@nc.rr.com>
To: Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: Future of ELKS
Date: Fri, 21 May 2004 02:08:59 -0400 [thread overview]
Message-ID: <006f01c43efa$1bedc550$0101a8c0@vash> (raw)
In-Reply-To: 40AD4286.1090801@cowlark.com
> 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
next prev parent reply other threads:[~2004-05-21 6:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-19 20:55 Future of ELKS Miguel Bolanos
2004-05-20 3:39 ` I'm in Void
2004-05-20 14:47 ` Miguel Bolanos
2004-05-20 11:42 ` Javier Sedano
2004-05-20 15:15 ` Miguel Bolanos
2004-05-20 15:37 ` Eduardo Pereira Habkost
2004-05-20 16:06 ` Andrey Romanenko
2004-05-21 5:51 ` Dan Olson
2004-05-20 17:30 ` Javier Sedano
2004-05-21 8:32 ` Gábor Lénárt
2004-05-21 14:15 ` Jody
2004-05-24 9:29 ` Gábor Lénárt
2004-05-24 18:20 ` Alan Cox
2004-05-20 23:43 ` David Given
2004-05-21 1:04 ` Stefan de Konink
2004-05-21 3:39 ` Chad Page
2004-05-29 16:58 ` Gregg C Levine
2004-05-21 5:55 ` Dan Olson
2004-05-21 6:08 ` Jody [this message]
2004-05-21 13:24 ` Eduardo Pereira Habkost
2004-05-21 16:30 ` David Given
2004-05-21 16:59 ` Michael McConnell
2004-05-22 12:12 ` David Given
2004-05-22 17:29 ` Chad Page
2004-05-21 18:38 ` Jody
2004-05-22 8:53 ` jb1
2004-05-22 17:00 ` Chad Page
2004-05-24 9:42 ` Gábor Lénárt
2004-05-20 16:54 ` Javier Sedano
2004-05-21 5:50 ` Dan Olson
2004-05-21 9:08 ` Arnaldo Carvalho de Melo
2004-05-21 10:24 ` Alan Cox
2004-05-24 12:20 ` Gábor Lénárt
-- strict thread matches above, loose matches on Subject: below --
2004-05-20 13:40 Pat Gilliland
2004-05-21 17:53 ` Miguel Bolanos
2004-05-20 20:18 Tommy McCabe
2004-05-24 13:17 BODRATO Stefano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='006f01c43efa$1bedc550$0101a8c0@vash' \
--to=jbruchon@nc.rr.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.