OSDev.org

I spent quite a lot time studying the segmentation of 80386, namely GDT, selector .. etc. After I learned how it works, I came up a question: why did intel introduce ‘segmentation’ to protection mode since it’s not necessary. 80386 is a 32-bit cpu and owns 32-bit address bus. Things could be more brief and clean.

Recently, I reviewed some material of intel’s protection mode, and suddenly I got the answer (in my view at least). The answer is: protection mode was introduced in 80286, not 386.

80286 is a 16 bit cpu with 24 bit address bus. When intel designed the protection mode, the engineers had to face a same question they had ever met on 8086 -------how to address the memory space beyond 64K. So they chose segmentation again, just as what they did under real mode.

What I want to ask is, I know, it’s a natural decision, but, segmentation is really a bad virtual memory protocol compared to paging. intel’s engineers should be very aware of this point at that time. The history also proved this fact –-------- Hardly any major operation system take advantage of x86’s segmentation protocol, they use paging.

80286 was released in 1982 and 80386 was released in 1985. If intel put off the introduction of protection mode until 80386, intel’s engineers could have designed a much more clean protection mode, they probably gave up the the concept of segmentation, since it’s not necessary on 80386.

Firstly you shouldn't be looking at it as "segmentation vs. paging", they're not mutually exclusive. Paging can (and is/was) used simultaneously with segmentation. What you're really asking is "why have segmentation, especially since some of it's capabilities are duplicated by paging?".

Secondly, segmentation was not primarily created to break the 64KB barrier of 16-bit addressing. It's a feature that originated in mainframe systems in the 1960s and 70s, many of which already used address sizes greater than 16 bits.

You're also wrong to claim that "hardly any major operation system" used segmentation. They all do to some extent, since unlike paging, segmentation is required by the x86 architecture. Although most "modern" operating systems just configure "segments" with base 0 covering the entirety of memory, that's not always been the case. Non-NT Windows (can't get much more "major" than that) and OS/2 used segmentation extensively.

Outside of x86, UNIX was originally developed on segmented memory architectures, something that's still evident in documentation (e.g. why is use of invalid memory called a "segmentation fault"?).

Segmentation does offer some advantages over "flat" memory arrangement, especially in the past when CPUs were a lot slower and a lot more code was written in low-level languages like assembly. For instance, you could use segmentation to implement a bounds-checked resizable array very easily, with zero performance cost and with pointers remaining valid after resizing. The whole reason for the existence of the LDT on x86 was to allow applications to manage their own segments with minimal assistance from the OS and allow this kind of programming.

With code developed in higher level languages, segmentation is awkward (nobody wants to go back to the days of "near" vs "far" pointers in 16-bit code) and poorly supported by modern compilers, so it's fallen out of favour. It's still possible to do some useful things with it, for instance, if you load all your program code at the beginning of memory and keep the code segment's limit at the end of the loaded code while keeping the stack and heap at the top of memory, you can mitigate some security flaws since the heap and stack wouldn't be executable (it wasn't until the "NX bit" was added by AMD in ~2003 that any form of data-execution blocking was possible without using segmentation).

Hi,



Paging was introduced when 80386 was released in 1985; but it took Microsoft until 1995 to release an OS that supported paging properly, and then it took another 10 years before people stopped using old applications for DOS and/or 16-bit Windows (that were designed for segmentation). Essentially, it took 20 years before segmentation truly "died". If Intel didn't provide backward compatibility for segmentation when 80386 was released, then 80386 would've been a failure and 80x86 may have ceased to exist.

Essentially, if you break too much backward compatibility too quickly it's suicide. You have to have a slow transition to give OS developers time to adjust to hardware changes, then give application developers time to adjust to OS changes, then give users time to adjust to application changes.

Note that the same happened for long mode (released in 2000, not "ubiquitous" until a decade later) and is currently happening with UEFI (released in the mid 1990s and still not "ubiquitous" 20 years later).

Intel’s engineers could have designed a much more clean protected mode, but they were smart instead.


Cheers,

Brendan

I also think one would need a more powerful CPU and more RAM and disk space to make good use of page translation and overall better non-segmented OS code. I think you wouldn't have benefited a lot from page translation on a 80386 with like 2 MB of RAM and a slow 100MB HDD or whatever was common in the early nineties. IOW, I think the slow adoption of the 32-bit goodies had also to do with consumer ability to buy a better PC. In this respect the timing was OK.

As for 64-bit x86 CPUs and hardware support for x86 virtualization, Microsoft started working on these in the early 2000's. There was even 64-bit Windows XP (not just 64-bit Windows 2003 Server), which had understandably limited use as most users were better off with 32-bit XP. Microsoft bought Connectix in early 2003 and it took several years (3-5 as I'm not sure when exactly the active work started; I joined in late 2005 and Windows wasn't yet booting in a Hyper-V VM) for the combined team to develop and ship the first version of Hyper-V (2008). It takes people and time to get serious stuff done and out.

And then new things started to converge and reinfornce one another. Better PCs <-> better software <-> better internet -> better everything. Not that it's a completely new trend, it's just something that's happened in the very near past that we were witnesses to.

A point to remember is that while Intel "released" the 80386 in 1985, early chips were very buggy and the first PC with a 386 wasn't released until late 1986 (and wasn't available in significant quantity until well into 1987). The chip was very much a high-end luxury until the cheaper 386sx was available (in late 1988). It really made no sense for a "consumer" OS to bother with 386-specific features (let alone requiring a 386) until at least 1989/90. Therefore, the fact that Windows 3.0 included full support for memory paging in 1990 (and Windows/386 used paging to emulate EMS and run multiple V86 sessions in 1987) and that Microsoft had a full "modern" 32-bit OS (Windows NT; intended for business/server use) in 1993 is pretty much as fast as was reasonable.

Of course, IBM had a 32-bit consumer OS with paging and a flat memory model (for 32-bit user applications; like Windows 9x, there was still a lot of 16-bit code around) in 1992 (OS/2 2.0) and 386 UNIX ports were using paging at least as early as 1988. Power users, developers and the like weren't waiting around for Microsoft to support their hardware.

I didn't mean that

I mean, iintel could have gave up introducing protection mode in 1982(namely, 80286) and designed it patiently together with the later 80386.

Then, the engineers should have a chance to gave up introducing segmentation to protection mode during the designation(segmentation is no longer necessary on a 32-bit cpu) . But on 80286, it's necessary, they have no choice.

Then, what intel needed do is design a virtual 8086 system on a non-segmentation protection mode for backward compatibility, i think it's possible.

The 80286 was a processor for its time. Limitations of how many transistors could be placed on a reasonable-sized chip controlled many of the design decisions. And a 24-bit address space wasn't a great limitation. In those days 16MB was a huge amount of RAM. It was a vast improvement on the 8086 and the disastrous 80186, and that was all that was needed in its time.

@mallard
Thanks for your reply, i learned a lot from your post. But i don't agree with some of your points.


Yes, segmentation was not primarily invented for memory addressing. But for intel, it is. Segmentation was twice introduced to x86, one time in 1978 for 8086 real mode, the other time in 1982 for 80286's protection mode, both time intel facing a same problem -----to address a memory space larger than it's ALU width. Of course, segmentation has other advantages(or say, usage), just as you said, be friendly(natural) with assembly program, be a way to implement virtual memory, etc. But for intel, these are just added benefits.


This is exactly what i care about. Paging can be used with segmentation. But not necessarily. Paging can take place of segmentation totally. MC68010 is a good example, which implemented paging only.
The lack of NX bit on 32-bit i386 is intel's fault, not paging's fault. We truly can get some more benefit from segmentation, but it's not necessary for a modern operation system.

So, my confusion is, in 1980s, since it's already predictable that segmentation would be eliminated by history, why did intel introduce it to x86 so impatiently ? Just wait for 3 years, intel's engineers would design a non-segmentation protection mode on 80386, just as MC68010 did. When designing 80286, They should clearly knew that such a complex protocol would be ignored by os developers soon and became a total waste of transistor.

Thanks Not a surprising answer, but really useful to me.

I don't know that I'd call the 80186 "disastrous"; it just wasn't very much of a step forward from an 8086 (in terms of capabilities) and didn't play well with the external versions of chips moved into the package.

Now, the i860 and i432, those were disastrous.

I worked for a medical accounting company which had been using Nova minicomputers and BASIC...

They found IMS/BASIC for SCO Xenix on 286 and were moving their customers on to this "new" processor...

I worked on Word Perfect integration.

The incredible thing - paging being the key point here - is we had customers with 32 wyse-50 terminals all tapping away on a 286 with 2mb of memory.... with at least half working in Word Perfect.

I have always been impressed by that.

While not specifically applicable to the 286, I should mention that I learned to NOT change the order of menu options when adding a new menu option - always append - never insert....

Why? Because these users had the menu entry number sequence ingrained in their muscle memory and changing the menu entry order would have them off in left field so quickly that within 10 minutes of issuing an update you would get tech support calls about "what screen is this???/"

cheers

The i432 was actually pretty incredible design. The compilers and marketing - total disasters... Ada.. bleh

Anyone looking at capability based systems should at least study the i432

In the case of the 8086, the reason (well, one of the reasons) was pretty much the opposite. In the 8080, the 8086's predecessor, the data paths were 8-bit, but they used two byte (16-bit) addresses, and with the exception of the accumulator (A), the registers (B, C, D, E, H, and L) could be paired (BC, DE, and HL) for addresses and other values that wouldn't fit in a single byte. However, when they worked on the 8086, the ran into two problems: first, most of the current hardware was made for either 8-bit or 16-bit data paths; and second, doubling the number of data pins would have made the Dual-Inline Package form factor of the planned chip too large (though other manufacturers would do exactly that for their 16/32-bit chips such as the Motorola 68000, and 32-bit chips such as the Zilog Z8000, shortly afterward). Furthermore, memory was so expensive that it was assumed that in the projected 3-5 year production life for the 8086 no one would even try to use a full 4GiB address space - not even mainframes of the time had that much.

They also wanted to make porting 8080 assembly source code easier, and requiring 32-bit addressing would break a lot of the assumptions of a lot of the assumptions such programs made.

So, the settled on segmentation - a well established, if rather unpopular and often derided, technique - as a compromise that would let the majority of programs use the same 64KiB address space, limit the total address space to a manageable 20 address pins, and allow the use of existing 16-bit hardware.

It was definitely a "it seemed like a good idea at the time" sort of thing, especially in light of the fact - which I have mentioned here numerous times - that the 8086 was seen as a stop-gap by Intel until a better embedded controller - the 8051 - and a high-end workstation processor - the ill-starred iAPX 432 - were completed. They were entirely blindsided by the PC, doubly so since they thought that home computers were a dying fad and had actually stopped selling chips to microcomputer builders in the hope that the whole thing would fade. They thought IBM was making a mistake with the PC, and assumed that Big Blue's long-term strategy was to drive the micros out and then slowly wind down the market and maneuver the buyers into using PCs as glorified smart terminals. This was in fact the plan, but needless to say, they both misread the situation drastically in a way that is comparable the plot of The Producers.

The 8086, 8088, 80186 and 80286 were "gap filler" CPUs that were only developed by Intel because the IAPX432 processor was delayed and had terrible performance.
http://archive.computerhistory.org/reso ... 01.acc.pdf

Bill Gates famously referred to the 80286 as a "brain dead" design (Wikipedia).

The Motorola 68010 was released the same year as the 80286 (1982). If my understanding is correct, it had proper 32bit paged virtual memory (similar to the 80386). Intel was way behind thanks to its obsession with the failing IAPX432.

The 80286 is one example of Intel's f#$k ups (clearly inferior to the 68010). Other examples of Intel f#$k ups are IAPX432, Itanium, ACPI etc.

Also a surprisingly high amount of arcade games used 80186 clones (without the integrated baggage, i.e. just the 80186 ISA), and I believe quite a bunch of Japanese computers did the same too. From that viewpoint, 80186 actually didn't really fare badly, just the original chip.


For the record, from what I've been reading everybody was criticizing IBM for even considering to attempt, even those who believed home computers were to stay. Indeed, it seems that early PCs did awful on the home market, the main customers for those were small businesses that couldn't afford a mainframe and jumped on board because they saw IBM's name on it (enough that IBM had trouble keeping up with the demand, actually... it seems nobody saw that one coming).

The irony is, those criticizing IBM for trying were also criticizing them for not doing it right before that (because they were getting their lion's share eaten or something like that). I guess loud people just wanted an excuse to complain.