AW: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

["Mario Premke" <premke@ess-ag.de>]

> The problem with using far pointers is that you end up having to encode
> segment IDs into the pointers themselves, which makes things
> really painful.
> Particularly, on systems that don't have an MMU, the segment ID
> controls the
> address of the segment; so on the 8086 and 8088 you won't be able to move
> your application's segments around while the program's running.
>
> (Brief tutorial on segments: the 8086, 8088 and 80286 are *not* 32-bit
> processors. They are 16-bit processors. They can address a total
> of 64kB of
> memory. However, they have a feature where you can select which 64kB of
> memory you want to use out of a much larger memory region. Each area is
> called a segment, and is referred to by segment ID. The processor can use
> different segments for accessing code, data and stack, so you can
> put your
> code in a different 64kB area than your data. The 8086 and 8088 have a
> hard-coded MMU where all segments are 64kB long and the physical
> address of
> each segment is (segmentID * 16); physical memory is 1MB wide.
> The 286 and
> above have a programmable MMU where you can vary the length and physical
> address of any segment at run time, and physical memory is 16MB wide.)

AFAIK the difference of a 286 and 8086 is that in x86 real mode the 'segment
ID' is part of a real hardware address whereas the 286 has memory protection
in protested mode and is able to hold a 64kB local descriptor table for each
process which holds the segment ID's in memory ... as far as I remember each
desriptor being 8 bytes long this results in 8192 adressable segments per
process ?!?

>
> Also, far pointers are slow and cause bloated and annoying code.
> One of the
> problems is that now your pointers are 32 bits wide, but your
> integers are 16
> --- and while this shouldn't affect well-written code, there's a lot of
> badly-written code out there.
>
> I'm of the opinion that a program that won't fit in a 64/64
> address space is
> too big to run well on an 8086-class system, anyway.
>
> (Incidentally, I dug out of storage an old laptop of mine: a
> 386SX/16 with one
> whole megabyte of memory. I installed Minix on it, telling Minix
> that it was
> a 286, and it runs fine! Recompiled the kernel and everything! It's a bit

I did the same on my 286 w. 5Mb Ram - I expected the Minix kernel
compilation to endure a while, but it finished (successful) after only ~15
min.

I only wanted to state that coding a 16bit OS and leaving out multiple
segments for code and data especially on a 286 with MMU and protection
capabilities would give away some (good) features. On the other hand more
than 64kB text and 64kB data might be rarely needed ...

Mario