Re: EDE - Personal Suggestions and Ideas

[Dan Olson <dano@agora.rdrop.com>]

> Think instead of traditional Unix segments. The 8086 is a 16-bit processor,
> which means each process can address 64kB of memory. Full stop. We don't even
> want to *try* to make it address more, it's just too complicated. However...
> which 64kB is being accessed depends on what the processor is doing at the
> moment (accessing code, data, the stack, or 'other'). That's very easy to
> support and allows considerable flexibility later.

I agree 100%, I keep seeing what look like very complicated ways to allow
large processes to run under ELKS, while I can't claim to be an ELKS
programmer, I tend to think that we are better off just keeping things
simple and small.

> So, if a process wants, it can allocate up to 256kB of memory. If it does, it
> needs to be specially written --- probably not in C --- but it can be done.

That's a good sized chunk of memory, if you concider that the OS and other
background stuff will be using memory too, about have of the memory on a
640k machine will be used once this one large process is run.  This also
make it possible to allow C without special concideration, and without
giving up the multiple segment feature that the 8086 allows.

> Except that in our case, pointers are always 16 bits. The compiler neither
> knows nor cares about segments. As far as it is concerned, it's using a flat,
> linear 16-bit address space with memory protection (even though on anything
> below a 286 there isn't any actual memory protection).

Very true too, I think the best we can do it to just assume that the
memory is protected, as we can't stop someone who really wants to write a
program to modify another process's memory, or prevent misbehaved
programs.  If that's a feature that's needed, the 8086/8088 is a poor
choice (without a MMU).

	Dan