Re: EDE - Personal Suggestions and Ideas

[David Given <dg@cowlark.com>]

On Friday 28 May 2004 12:23, you wrote:
> David Given wrote:
> >But if you're not programming in C, you don't have this limitation. Unix
> >traditionally is programmed in C, so people don't think about this much,
> > but it would be really nice if the kernel would manage all the segment
> > registers and not just CS and DS. So that, if you like, you could load a
> > binary that allocated all four segments. This would allow nice features
> > such as a Basic interpreter that stored its byte-code in ES, its working
> > stack in SS, and used DS for workspace.
>
> You propose to maintain two or more pointers that points to same memory
> location but to different areas that may cross over.

No! Nonononono! Dear gods, that's horrible!

I'm assuming that segments *never* overlap. Ever. (Except for the special case 
where two segment registers refer to the same segment.)

Don't think about nasty, hacked up 8086 multisegment executables and far 
pointers. These are irrelevant. We do not want to support this, it's a pain.

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'm not talking about binaries containing multiple code or data segments.

Currently, ELKS binaries (which are the same format as Minix binaries, 
although you can't run Minix binaries on ELKS) contain a header that 
contains, among other things, the size of the code segment and the size of 
the data segment. If we extend this with a couple of fields for the size of 
the stack segment and the size of the extended segment, with the proviso that 
0 means that they map onto the data segment, that's all we need.

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.

[...]
> I belive C programmer does not need to know about all this 8086's
> xxxx:xxxx memory structure at all.
> It is job of compiler to convert 32bit pointers to xxxx:xxxx addresses.

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

> So ideally there would be two types of executables: old
> (that we have now) and new with multi segments where compiler using
> kernel manages all segments allocation and converts
> 32bit pointers to apropriate locations.

I really don't want to support binaries containing multiple code and data 
segments. If needed, that can be implemented at a purely user level. But 
multisegment executables make life much, much harder.

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | "I have a mind like a steel trap. It's rusty and
| (dg@tao-group.com) | full of dead mice." --- Anonymous, on rasfc
+- www.cowlark.com --+