Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84; site aluxz.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!aluxz!pjb From: pjb@aluxz.UUCP (bednarczyk) Newsgroups: net.micro,net.micro.pc Subject: Re: Intel 286 microprocessor problems Message-ID: <199@aluxz.UUCP> Date: Tue, 4-Dec-84 13:12:17 EST Article-I.D.: aluxz.199 Posted: Tue Dec 4 13:12:17 1984 Date-Received: Wed, 5-Dec-84 00:25:59 EST References: <2672@cornell.UUCP> <50@tove.UUCP> Distribution: net Organization: AT&T Bell Laboratories, Allentown, PA Lines: 61 Xref: watmath net.micro:8831 net.micro.pc:2922 > > First, a quick tutorial for those unfamiliar with the 286: > > > > The 286 uses 32-bit virtual addresses (not quite, but almost). The > > upper 16 bits (essentially) specify a segment, and the lower 16 bits > > specify an offset. > > > > Whenever you change the upper 16 bits of an address, you change your > > segment, and the processor starts doing somersaults. That is, it > > checks for a segment descriptor to allow this segment to be accessed, > > it checks protection, checks data type correspondence, and even > > brings it in from secondary storage (hence implementing "virtual > > memory"). > > > > Intel, of course, claims that this is all an advantage. I'm not so > > sure. There are three things that concern me: > > > > Concern 1: > > > > With the arbitrary sized segments that they allow, there has to be > > some fancy operating system software that juggles these different- > > sized pages around in physical memory. Hence, it is not as transparent > > to the system as it might be. > > > > Concern 2: > > > > The 32-bit virtual address space is not really 32 bits - the least > > significant 3 bits of the top 16 (the segment part) are used for > > protection and code/data distinction. Thus, if I want to access > > some element in this 29-bit (yuck!) space, I need to shift all my > > upper halves of the addresses left by 3 bits. Why in the world > > didn't they stick these non-conformist bits in the high end of > > the address, so that we don't have to do this shift? This could > > be a very serious problem, since this shift has to occur for *every* > > memory reference! > > > > Concern 3: > > > > All right, I'm willing to put up with segment boundaries at every > > 64K that cause performance degredation when crossed, I'm not so > > willing to put up with shifting every address, but I'm astounded > > at the impracticality of the ENTER and LEAVE instructions, meant > > to help with high-level language execution. These instructions > > are meant to manage a stack frame (apologies to those that don't > > deal with compilers) with a display. HOWEVER, the display pointers > > are only *16* bits! Heck, it won't take much effort to write a > > nice, small recursive program that takes more than 64K of stack > > frame space! Sure, we can just ignore these instructions and > > create our own display with 32-bit pointer variables, but the > > ENTER and LEAVE instructions are 2 of the 3 instruction set > > extensions of the 286 over the 86 and 88, the other being block > > i/o. What a waste of effort. > > > > > > Am I missing something fundamental, or are my concerns valid? I > > just read the manual over the weekend, so maybe something didn't > > click. Any solutions to the above problems are welcome. > > > > Doug Campbell > > doug@cornell.{UUCP|ARPA} > > *** REPLACE THIS LINE WITH YOUR MESSAGE ***