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}

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

Message-ID: <451@ima.UUCP>
Date: Thu, 29-Nov-84 23:37:21 EST
Article-I.D.: ima.451
Posted: Thu Nov 29 23:37:21 1984
Date-Received: Sun, 2-Dec-84 02:42:13 EST
Lines: 26
Nf-ID: #R:cornell:-267200:ima:11700003:000:1397
Nf-From: ima!johnl    Nov 29 12:54:00 1984

You're right.  The 286 segmentation is a big pain in the neck if all of
your data doesn't naturally fall into 64K or less chunks.

Having your code in multiple segments is not much of a problem, since there
are long call and return instructions that do pretty much what you want.
But dealing with multi-segment data is hard, and multi-segment stacks are
nearly impossible.  As noted, the low three bits of a segment number are
magic, so to simulate linear addressing, you have to do a lot of shifting
and masking.  Also remember that the 286 won't access operands over a segment
boundary, so that if you have an array of structures, you have to make sure
that no structure is partially in one segment and partially in another,
because it won't work.

Finally, simulating large data is very, very, slow.  Most data manipulation
instructions take 2 or 3 cycles, but reloading a segment register takes 17
cycles because of all of the table lookup the microcode has to do.  And is
the CPU smart enough to notice that the new ES value you're loading is the
same as the current one?  Don't be silly.

Vague claims have been made that the 386 will have 32 bit registers and
large paged segments (the 286 segment descriptors have lots of bits
reserved for 386 expansion) but I'm not holding my breath.  Perhaps I
can interest you in an NS16032.

John Levine, ima!johnl (uucp), Levine@YALE.ARPA (Internet)

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

Message-ID: <20300017@okstate.UUCP>
Date: Sat, 8-Dec-84 23:03:00 EST
Article-I.D.: okstate.20300017
Posted: Sat Dec  8 23:03:00 1984
Date-Received: Wed, 12-Dec-84 03:21:40 EST
References: <2672@cornell.UUCP>
Lines: 11
Nf-ID: #R:cornell:-267200:okstate:20300017:000:407
Nf-From: okstate!kermit    Dec  8 22:03:00 1984


[munch...munch...munch...]

This past week, Thursday, December 6 to be exact, I was fortunate enough
to talk with a INTeL salesman/spokesman.  The word is that the 386 will
operate in 2 modes.  The first being segmented and compatible with the 
rest of the family, and the second being a direct access mode allowing
non segmented operation throughout the addressing space.

Gregg Wonderly 

Message-ID: <3@spar.UUCP>
Date: Thu, 13-Dec-84 16:08:42 EST
Article-I.D.: spar.3
Posted: Thu Dec 13 16:08:42 1984
Date-Received: Sat, 15-Dec-84 02:06:57 EST
References: <2672@cornell.UUCP> <20300017@okstate.UUCP>
Organization: Schlumberger Palo Alto Research, CA
Lines: 25

>                                           The word is that the 386 will
> operate in 2 modes.  The first being segmented and compatible with the 
> rest of the family, and the second being a direct access mode allowing
> non segmented operation throughout the addressing space.

Well, I attended a seminar in Santa Clara on future intel products some
months ago, and the story *then* was that the 386 would have 3 modes of
operation:  An unmapped, vanilla 8086 mode, a 286 mode, and a 386 mode,
each selected by mode control bits in the PSW.  In 386 mode, it was still
to be a segmented machine, BUT the segment offsets specified in an
instruction were to be 32 bits instead of the traditional 16 bits.  Thus
each segment is effectively 4 Gigabytes, which is pretty reasonable.
The segment registers themselves add even more bits to each virtual
address, and they talk of multi-terabyte virtual address spaces, but
the physical address space will be smaller.  Of course, it'll be a
tough job just building a machine with the performance characteristics
that they are promising for the 386 without carrying all that compatibility
baggage around.  It won't surprise me in the least if they have to back
off somewhat.

Kevin D. Kissell
Fairchild Advanced Processor Development
uucp: {ihnp4 decvax}!decwrl!\
                             >spar!kissell
    {ucbvax sdcrdcf}!hplabs!/

Message-ID: <332@cadovax.UUCP>
Date: Wed, 12-Dec-84 17:46:58 EST
Article-I.D.: cadovax.332
Posted: Wed Dec 12 17:46:58 1984
Date-Received: Sun, 16-Dec-84 02:48:09 EST
References: <2672@cornell.UUCP>, <20300017@okstate.UUCP>
Organization: Contel Cado, Torrance, CA
Lines: 8


>                                 ..... The word is that the 386 will
>operate in 2 modes.  The first being segmented and compatible with the 
>rest of the family, and the second being a direct access mode allowing
>non segmented operation throughout the addressing space.

I just love bolt-ons......