Re: Future of ELKS

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

*snip*

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

Disclaimer:  I don't know a ton about low-level 8086 programming, only
pieces, please correct me if I am wrong as it will benefit myself as well
as the community.

I was trying to hint that we should try to use less than 64KB per process
in another unquoted snippet...I don't know everything about 8086's but I do
know that there are PLENTY of operating systems from the past that have
done "a lot of stuff" in what we now see as a miniscule space.  I've seen a
program in less than 256 bytes (1 page in 6502 memory space) of 6502 asm
that would do a dual-algorithm decompression of the data it was attached
to.  I myself wrote an RLE decompressor to be attached to a BASIC program
that took up 110 bytes of code and about six bytes of data.  It's not
8086-related per se, but it does show that it can very well be done.  Also,
remember that good old DOS ran on PCs with 256KB of RAM or *less*
sometimes, and still did a lot of useful things.  Eventually, even when DOS
was rewritten in C (MS-DOS 3.0?) it STILL ran on ancient and "modern"
configurations.

Anyone who thinks we should eat one or two entire segments for a program
like cp, mv, rm, mkdir, or kill, is in my opinion self-limiting to the
segmentation of the architecture.  Please "think outside the box" on this.
If we write a good memory manager and programs honor the allocations of
that memory manager, there is no reason we can't break processes down into
smaller pages.  A relocatable executable format rather than dependency on
segments to do everything for us would probably help.

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

I certainly believe that 128KB is more than enough for a lot of things, and
that we're so used to inherent code bloat in both Linux and Windows that we
don't remember the "old ways" of coding sometimes...it's all about
squeezing that last 64 bytes, no?
What can I do in 64 bytes?  With my favorite CPU (6502) I can write a
routine that'll clear the entire contents of the C64's 320x200x1-bit screen
so it can be used for something, like a GUI.  I can write something that
will act as a supplementary buffer for my serial port.  I can store a small
icon (say a 2-bit color 16x16 icon for a CGA screen) for my simple
GUI...why use 64KB per process when we're already so limited and you don't
need all that?  Simplified versions of stuff like cp and mv could take only
a few kilobytes at most if written strategically.

I'm too lazy to type more, please respond to my comments ASAP so hopefully
I get them before work.  Everyone take care, and good hacking!

Jody