Message-ID: <2672@cornell.UUCP>
Date: Tue, 27-Nov-84 14:07:00 EST
Article-I.D.: cornell.2672
Posted: Tue Nov 27 14:07:00 1984
Date-Received: Wed, 28-Nov-84 04:27:31 EST
Distribution: net
Organization: Cornell Univ. CS Dept.
Lines: 61


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}