From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas] Date: Wed, 26 May 2004 11:09:41 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200405261109.41177.dg@cowlark.com> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Id: Content-Type: text/plain; charset="us-ascii" To: linux-8086@vger.kernel.org On Wednesday 26 May 2004 07:20, you wrote: [...] > What about supporting 286 protected mode in a manner that more than one > text+data segment per program are possible - still far-pointers were to be > implmented, but would segment switching not be easier with HW-protection > (in comparison to 8086)? I am not familiar with compiler programming, so > I have no idea of how much work it would be. > The last time I looked into the elks sources there was code for > initializing 286 protected mode - don't know if it works. 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.) 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 slow, but I wasn't really expecting otherwise.) -- +- David Given --McQ-+ | dg@cowlark.com | "Two of my imaginary friends reproduced once ... | (dg@tao-group.com) | with negative results." --- Ben, from a.s.r +- www.cowlark.com --+