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 ***
johnl@ima.UUCP (11/30/84)
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)
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 ***
kermit@okstate.UUCP (12/09/84)
[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 <kermit@okstate>
keithd@cadovax.UUCP (Keith Doyle) (12/13/84)
> ..... 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......
kissell@spar.UUCP (Kevin Kissell) (12/14/84)
> 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!/