Re: Future of ELKS

Gábor Lénárt
2004-05-24T09:29:02Z

Hello,

On Fri, May 21, 2004 at 10:15:23AM -0400, Jody wrote:
> 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.

Yes, some guys even does not beleive in his eyes when something runs with
less powerfull hw than a typical m$ os requires ;-))
Though it's not so amazing for me, since I've coded even tcp networking
for C64 once, though it was not finished at all becouse of lack of enough
free time (as usuall ...).

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

65816 has got 24 bit addressing (with storing bank number at the opcode
as well) but the area of these instructions are much weaker than bank
based instructions which work with the current data bank or such, and so on.
So it is not a TRUE 24 bit linear addressing platform, but it is closer the
goal than eg Enterprise with Z80 CPU where external logic maps some parts
of the 4Mbyte address space into the 64K address space of the Z80 CPU, sure
:) Sorry, though I'm familiar with 6502 and eg Z80, 65816 is known a little
by me, I've read only some dox, several years ago so maybe my knowledge on
it is quite limited ...

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

OK, my only though was that even some 8bit hw has got the power to run an
ELKS-like OS. Just think on Enterprise-128, I've described above (4Mb
addressing page with "paging", though the base machine has got only
128K RAM by default, you can expand it).

This is quite interesting for me, since I've started develope a cross
platform '8 bit' OS tough not in C but mixed assembly and a 'C subset'
language, with a layered design (a 'monitor' layer with detect hw, provide
low level access to the hw, and loads and links the kernel & other drivers
on booting, and the arch independent kernel which only depends on the CPU
type, so all Z80 based machines should have run the same kernel but of
couse different monitor).

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

Hmmm. I've known that it would be too complex to create a CPU with
linear addressing of 20bit address space (1Mbyte) so they've implemeneted
a segmented model. Sure, I could be wrong on this.

> 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

Some C compilers for 8086 CPU was able to create multi segment programs
with even 'far' functions, pointers etc ... Of course it's quite ugly
compared to a linear model, but an optimalizing compiler should solve
the problem to do this quite efficiently eg with trying to keep stuffs
in one segment which refers each other quite often, or such.

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

Hmmm, the only problem with a native ELKS C compiler (which run on ELKS) is
optimalization. It's not too hard to write a C compiler. Even for resource
weak systems. But good optimization done by a modern compiler requires quite
large amount of CPU power and memory. So maybe it's quite hard to transform
a good old XT into an ELKS development and programming platform ;-)
Though I've write compiler myself it was for a self constructed language
and not for C (though the compiler itself was written in C), so 'writing
a C compiler' is not a topic which is known too much by me, as you see ...

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

:)

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html