Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site tove.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!tove!iseki From: iseki@tove.UUCP (Osamu Iseki) Newsgroups: net.micro,net.micro.pc Subject: Re: Intel 286 microprocessor problems Message-ID: <50@tove.UUCP> Date: Thu, 29-Nov-84 14:09:14 EST Article-I.D.: tove.50 Posted: Thu Nov 29 14:09:14 1984 Date-Received: Sat, 1-Dec-84 19:10:41 EST References: <2672@cornell.UUCP> Distribution: net Organization: U of Maryland, Laboratory for Parallel Computation, C.P., MD Lines: 61 Xref: godot net.micro:3142 net.micro.pc:1525 > 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 ***