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