From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mario Premke" Subject: AW: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas] Date: Wed, 26 May 2004 13:34:36 +0200 Sender: linux-8086-owner@vger.kernel.org Message-ID: References: <200405261109.41177.dg@cowlark.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200405261109.41177.dg@cowlark.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: David Given , linux-8086@vger.kernel.org > 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