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

Gábor Lénárt
2004-05-26T12:09:12Z

Re,

On Wed, May 26, 2004 at 01:34:36PM +0200, Mario Premke wrote:
> > 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.

Yes, unless you provide a mechanism which notifies a process that it
SHOULD (must) "recalibrate" all of its far pointers or anything which
uses segment numbers as well. I've described it in my last mail.
However it would be really ugly and UNIX-alien technology ;-)

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

Yes, something similar, I haven't work with this for ages either :)

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

Hmmm, maybe a process can require a memory model at starting up.
Or we can allow to allocate multiple segments. But a process could allocate
only one. Or whatever. So now it's up the application to use a single
code and a single data&stack (for example) segment (with a given limit of
course, it can allocate less memory than 64K as well of course) or it
can allocat multiple segments even for only code, it's up the process.
The kernel side is not too different since only some mapping is needed
to know the memory allocation table of a process and so on.
Someone may want to write a multi segment application in assembler without
the knowledge of C 'pointer' and 'far pointer' problem, only knowing
assembly, and (s)he will be happy with the situation without any fear of
C pointer questions ;-) Yes, I remember when I write a lot in x86 assembly.

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

Maybe. Maybe not ;-)

- 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