Re: Future of ELKS

["Jody" <jbruchon@nc.rr.com>]

*snip*
> Just visist www.cc65.org.
>
> It's a C compiler (OK, it does not support all of the ANSI C though) for
> 6502 CPU family like 6510 used in Commodore 64. And there IS a full
> GUI/Internet (!) enabled Operating System for C64 which is written in C,
and
> cc65 was used as C compiler for this project. This OS is named Contiki,
and
> it DOES support TCP/IP and others on an UNEXPANDED Commodore 64 (yeah,
64K
> RAM and 8bit CPU running @ ~1MHz). Just visist:
> http://www.dunkels.com/adam/contiki/ Contiki was ported to other systems
as
> well, even x86.

Contiki is certainly an example for the little guys in the computer world,
proving that we can get stuff like a primitive port of Lynx running in a
cramped memory space.

> Ok, sure, cc65 can not compile itself, but 6502 CPU is a very limited
> one compared even to 8086, the stack space is only 256 bytes, for
example.
> [so cc65 is a cross compiler]

65xx/65816 are my most favored series of CPUs, and while the '816 has no
MMU or anything, it DOES have full 24-bit addressing instructions available
(NO SEGMENTATION) and a lot of other goodies that the 65xx didn't have, and
it only had 256 instructions so I suppose you would call it a RISC 16-bit
CPU. :)

> Sorry, if this news is OT here though :)

Slightly off-topic, but of course anything discussing stuff similar to ELKS
(running modern-ish stuff on really old hardware) and the possibility of
using that to enrich ELKS would always be welcome 'off-topic' conversation
for ELKS.

> The only meaning of my mail is the fact that 8086 if far much powerfull
CPU
> than 6502, so it SHOULD BE possible to write a good C compiler for it
> which can even compile itself :) Though of course it should not be an
> amazing fact, since some (...hmm...) years ago, 8086 was new and fresh
;-)

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...but even then, we DO
have two advantages over 'RISC-like' CPUs such as the 65xx[x] series with
our 8086/88 CPUs:

1.  CISC coding on the 80x86-series does more work with less memory
(unfortunately with more clock cycles though), thus saving us memory if we
(or our compiler) use the code very well, and
2.  The 80x86 has more than 64KB of RAM, typically 256KB (our minimal
target system) and up.

Considering that we are able to save memory with a complex instruction set,
and have more memory to work with as well, I think that anyone who writes a
program (save the kernel perhaps) that uses up more than 64KB of RAM in the
first place is either A: not writing the program with memory usage in mind,
which is critical on this platform more so than the 386+ counterparts, or
B: undertaking a LEGITIMATELY LARGE task, such as an X-like GUI or a C
compiler implementation.  For a minimal system of 256KB, we'll need the
core stuff (kernel, init, sh) to run in less than 128KB or so combined
(very very possible, especially with modular and optimized drivers when we
get there) and the C compiler to use around 128KB total, perhaps with some
sort of work file on a block device if it needs more space.  That's what
temporary files are for, no?

Just my $0.02, let me know if any of that stuff helps anyone.  I'm trying
to learn some C coding, so I can do something worth something on ELKS
instead of talking about it all the time, telling developers what direction
to go in, and saying "I'll write documentation for it but I can't yet
because it doesn't have a LILO equivalent yet..."

Jody