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