doug@cornell.UUCP (Douglas Campbell) (11/27/84)
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}iseki@tove.UUCP (Osamu Iseki) (11/29/84)
> 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 ***
pjb@aluxz.UUCP (bednarczyk) (12/04/84)
> > 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 ***