It turns out that there is a rather interesting story behind the 286 XENIX incompatibility with 386 and later processors. Here’s roughly what happened in chronological order.
In 1982, Intel released the iAPX 286 processor, later known as the 80286 or simply 286. This was a highly complex CPU for the time, with an intricate system of software privilege and security enforcement known as protected mode. The 286 used descriptor tables with 48 bits (6 bytes) of information, but in order to keep the design simple, full 64 bits were taken up for each descriptor; the last 16 bits were not used by the CPU and were documented as reserved.
Later in 1982, work was also underway on the 386, Intel’s 32-bit successor to the 286.
In late 1982 or in 1983, Microsoft ported XENIX (a variant of UNIX System III licensed from AT&T) to the Intel 286 processor. Intel and IBM were among companies which licensed the 286 XENIX port from Microsoft. Although Intel had the XENIX source code, the porting was done entirely by Microsoft. Developers at Microsoft decided to store bookkeeping information in the “reserved” 16 bits of a descriptor table entry not used by the 286. This approach reliably worked on 286 processors.
Circa 1983, Intel’s design of the 386 became more fleshed out. The 386 used descriptor tables which were an extension of the 286 variant. Notably, the previously unused word was fully used and Intel utilized it to extend the segment base (24 to 32 bits) and add new attribute bits.
In late 1983, updated 286 documentation marked the last 16 descriptor bits as “reserved for iAPX 386, must be zero”.
In Summer 1984, Intel had the first A-step samples of the 386 and validation was in full swing. A logical target was 286 XENIX since it was a product Intel sold and an operating system which utilized the 286’s protected mode.
Intel discovered that 286 XENIX does not work on the 386 at all. Engineers quickly realized that the problem was not with the 386 design or silicon but rather with the fact that Microsoft chose to use the reserved descriptor word ignored by the 286, and the 386 interpreted the data in unexpected ways (which immediately crashed the OS).
Since Intel engineers had access to the XENIX source code, they were able to re-code the OS not to use the reserved descriptor word. Microsoft was reluctant to accept the patch, claiming that there was nothing wrong with their code.
The matter was quickly escalated and sometime in late Summer 1984, Intel engineers met with higher-ups at Microsoft. Bill Gates argued that he knew how to get the most out of hardware, that Intel should listen to Microsoft, and that the 386 needed to be changed. Intel argued that Microsoft should not have been using reserved areas; Intel also really didn’t want to change the 386 design at that point because A0-stepping engineering samples were already in customers’ hands. Microsoft pointed out that if Intel didn’t want programmers to use reserved areas, they shouldn’t have let them use those areas in the first place.
Intel did not change the 386 design but took heed of Microsoft’s admonition. It was a lesson learned—if you want to keep certain areas reserved, you must actively keep out intruders. Otherwise there is a risk that reserved bits can’t be repurposed in the future because changing their semantics would break too much existing software.
In late 1984, IBM XENIX 1.0 for the PC/AT was released. It contained the original Microsoft implementation which puts data in a reserved descriptor word. Since there were no 386s available yet and IBM XENIX 1.0 was bolted to the specific PC/AT models anyway, that did not pose practical problems to IBM’s customers.
In October 1985, Intel released the 80386. The 386 was a somewhat sloppy design which allowed users to set certain bits documented as reserved. The 386 programming documentation explicitly listed the use of the last 16 bits of a descriptor table entry as a visible behavioral difference between the 286 and 386.
In April 1989, Intel announced the i486 processor. The i486 was essentially identical to the 386 in its treatment of reserved bits. It is likely that Intel wanted to make minimal changes compared to the 386, possibly in part because they could not be certain who might be incorrectly setting reserved bits.
No later than Summer 1990, Intel completed the P5 (later known as Pentium) external design specification. The Pentium design was significantly different from the 386/486; it took the 286 XENIX lesson to heart and actively prevented programmers from setting reserved bits in control registers or page tables. This was done by raising an exception when an attempt to set reserved bits was made. The strategy was adopted by follow-up CPUs which raise exceptions whenever the user tries to set a reserved bit in control registers, page tables, MSRs, etc. This approach makes controlled expansion of the architecture viable because existing software does not suddenly produce completely unexpected results on newer CPUs which additional control bits. The P5 documentation explicitly listed exceptions due to setting of reserved bits as a difference from the i486.
In early 2017, the story came out in an e-mail discussion with a former Intel validation engineer.
Which made me wonder about the removal of the test registers.
Yes, because that did break existing software. Perhaps in 1993 Intel simply figured that they were big enough and didn’t need to care anymore. That definitely wasn’t the case in 1985, and possibly not even 1989.
I am talking about the same P5/Pentium that did reserved bit checking though.
Bill Gates basically telling Intel that Microsoft knew more about the 386 even though Intel created the chip and the overall architecture is incredible arrogance and hubris. Doubly so considering that Microsoft always had many undocumented “reserved” functions and structures in much of their software.
It was more like that they think they can use the reserved bits just because it didn’t cause any problems on the 286.
@dosfan: Do you know anyone that chose to use ISIS or RMX? Intel did not have much market success in the field of OS design. Intel didn’t even have a good track record of permitting old code to run on new OS versions despite formally eschewing reserved functions.
The 80s were rather interesting to watch as the programmers that started in the 60s and 70s trained to minimize unused memory butted heads with the newer programmers that cheerfully wasted memory. Wasn’t just MS, the Mac programming team exploited unused addressing bits before 32-bit clean became a mantra and DRI painted itself into a corner with a file system that couldn’t accept umlauts in the file extension because high ASCII bits carried file system metadata.
Mac OS kept some memory manager flags in the unused bits of the address. The Mac OS devs realised their mistake and moved the flags out of the address but by that point, app devs were routinely twiddling the flag bits directly. If the app devs hadn’t done that then it would have been much easier to upgrade.
Read http://www.folklore.org/StoryView.py?story=Mea_Culpa.txt
It wasn’t exactly telling Intel that they (MS) understood the 386 better, “only” that they understood software better and Intel should not be getting in their way. There certainly was some arrogance and hubris involved.
And yes, we know how much Microsoft liked it when 3rd parties made use of undocumented areas/features of their own software 🙂
I’ll have to concur with Intel’s interpretation. Reserved is reserved — it’s one’s own damn fault if one violates the spec like that.
That said, IME, conscious refusal of necessary patches (or even refusal to get the point they address!) is rather the norm in most software projects. I’ve always wondered why.
@comments: I suppose a general rule for a good design is: don’t take shortcuts, ’cause sooner or later, they’ll come back to bite you in the butt!
The counterargument is that without shortcuts, you might never have a successful product and architectural extensibility would be the last thing you’d need to worry about.
Not saying it’s a good argument, but you have to wonder. If IBM designed the PC “properly”, would it be such a hit? Would there be so many clones? Or would it have gone the way of the PS/2? Sometimes (like the Xenix or Macintosh case) it seems the shortcuts were pretty obviously a poor decision, lot of trouble for minimal upside, but it’s not always so clear cut. As always, hindsight is 20/20.
It might not have been such a hit, but I think that IBM would still have had a pee-cee business to this day.
Oh, and I’ve found that ‘extensibility’ goes hand in hand with clean design. YMMV, however :^)
Certainly. All I’m saying is that clean design is expensive, time-consuming design. Not that it’s bad design 🙂
Personally, I tend to read the history of especially the IBM PC as one long cautionary tale.
@zeurkous
No matter what IBM would have likely lost control of the PC market because they simply didn’t understand the consumer market. I worked there and saw this lack of understanding first hand.
@dosfan:
I am under the impression that what was supposed to set the IBM PC apart from home computers is that the former was more businesslike, more suited for the office. If that’s right, then the IBM PC could still have prospered in that market.
Or am I being naive?
As a sidenote: Microsoft used similar technique when they developed AmigaBasic for Commodore Amiga. When AmigaBasic was designed, Commodore used only Motorola 68000 processors, which are internally 32-bit, but externally had only 24-bit address bus.
So, Microsoft went ahead and used most significant bits from some address registers as internal flags, even though this was explicitly disallowed by Commodore’s programming guidelines. And, when Commodore released machines with 68020 and later CPUs, AmigaBasic didn’t work that well.
Commodore wasn’t pleased.
@zeurkous
That’s true and IBM does understand the business market but once the older computers died and PCs became commonplace IBM really didn’t know what to do as they didn’t understand the consumer market at all. Many of IBM’s upper management in the 80s and 90s came from the mainframe arena where IBM completely dominated all aspect of that market. They didn’t know how to deal with a market they didn’t control and generally made incredibly bad decisions. Look at stuff like the PCjr and PC DOS 4.0, both major flops. Look at how they mishandled OS/2. They also made decisions to waste lots of time and money on stuff that no one really wanted like Workplace Shell for DOS which was a fiasco of epic proportions and OS/2 for the Power PC which was another disaster. Also many of their managers were very much like the manager from Dilbert with little or no technical understanding whatsoever and they tended to not listen to those who knew best so they were pretty much doomed to fail.
Lion food.
So, we might not be too far off if we conclude that IBM’d better not have entered the pee-cee market at all?
The IBM PC was incredibly profitable. In 1986, PC sales accounted for $7 billion while all of IBM only had $12.3 billion in revenue. IBM showed $1.3 billion in earnings but the ESD had roughly 50% margins so PC profits should have exceeded $3 billion. No IBM PC and IBM would have had to significantly shrink in the 80s; the PC staved IBM’s decline by a decade.
IBM’s mistake was trying to lock down the market to get higher margins which shrunk their sales volume. Very counterproductive. Before the PC Jr and Topview, the entire market waited for IBM to signal a direction which largely killed companies like Tabor. After those products and the relatively poor introductions of the PS/2 and DOS 4, the market would wait to see if IBM succeeded before following and sales became harder.
The IBM PC had a design that was flexible enough to last a decade without requiring major incompatible redesigns. That put it ahead of most of the other personal and home computers and even ahead of workstations like the Lilith.
I believe I may have misread The New York Times article I took the preceding figures from. I think the ESD figures were annual while the IBM total figures were quarterly. Thus, ESD was a major portion of the profits IBM showed but not the only part keeping IBM afloat.
I apologize for the mistake and the inability to edit previous post.
I believe I may have misread The New York Times article I took the preceding figures from. I think the ESD figures were annual while the IBM total figures were quarterly. Thus, ESD was a major portion of the profits IBM showed but not the only part keeping IBM afloat.
I apologize for the mistake and the inability to edit previous post.
It’s fine. Your point largely stands.
Though I’d argue that more trendy companies, like Apple and Sun, sure seemed to release redesigns at a faster rate than was strictly necessary. Pride in craftsmanship, I’d rather favourably interpret, but I’m well aware that, especially at a time that pee-cees were a lot more expensive, buyers preferred some stability. That’s very unlike how things are now, when a new dumb PDA (aka ‘smart phone’) is often acquired at the tip of a hat. Times change…
…not that I’m *that* eager to change w/ them :^)
There was also the Altair of course. Unfortunately I think ANSI/ISO and other standard committees was probably poorly suited to setting standards in this area. The right way back then would probably be to design a reference system and release schematics and other design information.
@Yuhong Bao: the irony is that that’s exactly what IBM did. I suppose they simply saw a gap and jumped in it, and as so often in these cases, the rest is history.
IBM did release the schematics for the 5150. Their openness for what became the ISA bus was one reason why the PC was so successful. They relied on the BIOS (the source of which was readily available) as being their keys to the kingdom. Those pesky clean room reverse engineers ruined that party for them.
I’d really like to know what the management at IBM was thinking when they decided to tightly control and license Microchannel. It was expensive to implement as it was, and the fees certainly weren’t attractive to system builders worried about their bottom line. The irony of MCA is that most systems were still hobbled by a 16-bit bus (32-bit datapath and addressing were the big reasons for MCA to exist!) since IBM kept on selling tarted up 386SX/486DLC PS/2s instead of 386DX and true 486 machines….. for much more then the clones with the true 32-bit parts.
To be honest, even Ed Roberts mentioned in http://www.virtualaltair.com/virtualaltair.com/mits0011.asp that “We should have copyrighted the name or patented the bus”.
Schematics (and BIOS listings) were published up to and including the XT Model 286 (1986). The next thing out was PS/2, far more closed.
I really don’t think that the IBM PC designers worried about folks reverse-engineering or cloning anything. They didn’t know they were creating a major force.
Besides, many businesses would still go for those three magic blue letters, or so they expected, didn’t they?
@Yuhong Bao: I figured. Few would start a company without the intent to make a heap of cash.
Yet another reason why Microsoft is evil. They write XENIX to their spec, then demands Intel change their silicon to suit their needs. Pitiful.
IBM had to include full schematics with the 5150. In 1981, IBM was still under the Consent Decree which required IBM to provide repair and interoperability information with all systems. Between 1982 and 1994, parts of the Consent Decree were lifted and IBM stopped releasing public information as it was no longer required to.
I never understood why IBM was unprepared for PC clones; they already had a decade of experience competing with Amdahl’s mainframe clones.
Wasn’t Amdahl the guy who coined the term ‘FUD’ in the first place?
I wasn’t aware of that decree.
Yes, that was the 1969 consent decree that forced IBM to unbundle hardware, software, and services. It’s pretty well known in IBM history, and a lot of ex-IBMers also tell me that it’s why IBM became the stingy IP holder they became.
Prior to that, IBM basically just included all the software you could ever want (and even some development services) at no extra charge when you bought a mainframe. It’s why old mainframe OSes are public domain: IBM never asserted copyrights on them and distributed the source code with them. At the time, IBM saw no profit in software, just hardware, so they just gave it all away.
I’m not very well versed in general IBM history. Thank you for the exposition.
Actually, using Internet Explorer instead of Microsoft Edge for some reason (as well as using a different email address) seems to have corrected this issue for some reason, though I’m still not sure if my posts will actually be approved, since I remember trying to post here a couple of years ago (under a different user name), and my posts were never approved for some reason, and I suspected that I was somehow being mistaken for being a spammer.
The post that I was talking about earlier was about the old A0 stepping 386s and whether they supported the virtual 8086 mode of operation that the production units supported.
Well, this one made it (and your preceding post which listed your e-mail addresses and which I didn’t publish). Comments would be rejected if they’re coming from a blacklisted IP address, but then changing browsers wouldn’t help you. Or if Akismet classifies them as spam. Why changing browsers should make a difference I can’t say, but it’s at least plausible. I did not knowingly delete/block/whatever any post about A0-stepping 386s and V86 mode.
Does anyone know if the early (prototype samples of A0 stepping) 386 CPUs supported the Virtual 8086 Mode? I found the “Product Preview” (as Intel called it) on the Bitsavers.org website, but I found no mention of Virtual 8086 Mode there, even though other features of the 386 and higher were clearly being discussed, such as 32-bit support and paging.
I also found a picture of what appears to be an early Intel 80386 A0 engineering sample with a 1985 copyright date, though it was labeled as a mechanical sample, meaning that I’m not sure if it was even functional or not.
“Does anyone know if the early (prototype samples of A0 stepping) 386 CPUs supported the Virtual 8086 Mode? ”
Although the silicon could not be verified, the first Deskpro 386s to appear on display must have had the A0 stepping. We waited two weeks of begging to touch it at the store. When the manager finally let us at it, we ran 2 benchmarks, and 4 dos windows. ( from Windows/386, which we promptly, backed up onto HD Floppies.
The two benchmarks we ran were LandMark, which was the fastest we’d seen at that point, a year later, at the computer shows, every single machine would run it, and TechPCs FPU ( 8087/80287 ) benchmark, which was exciting because the FPU was now bus independant. ( full 16Mhz, vs 2/3s of 8Mhz for the 286).
Yes, Virtual 86 mode worked out of the box.
And Yuhong Bao: If the Magna Carta was written in French, would we be speaking Polish? Who knows? The Standards committees were composed by a few of the brightest minds in the industry, along with some of the most treacherous marketing hacks known to man. A few times the brilliant minds would win, but mostly it was the marketing hacks, until the brilliant minds figured out that they could start the process late, and then the marketing hacks would no longer be interested.
Windows/386 on the first Deskpro 386s? That sounds unlikely. As far as I know, Windows/386 came out around September 1987, while the Deskpro 386 was introduced in September 1986.
Windows/386 (version 2.01) includes the following string: “The Intel 80386 CPU in this computer does not reliably execute 32-bit multiply operations. Windows will USUALLY work correctly on computers with this problem but may occasionally fail. Contacting your hardware service representative and replacing your 80386 chip is strongly recommended.” I have trouble finding a reliable information about which stepping or steppings had the multiply problem. If it was the B1 stepping then it doesn’t tell us much, only that Windows/386 worked (maybe) on the B1 stepping.
There’s also another error string: “Error: Unsupported Intel 80386 CPU version” — and that strongly implies that there were some 386 steppings that were just too broken or non-functional to even run Windows/386 at all.
Update: Windows/386 2.01 tests for the presence of the XBTS instruction. If XBTS is found, implying a 386 B0 stepping or earlier, Windows/386 refuses to run with the above error message. So… I don’t know. It’s clear that Microsoft considered the A-steppings and the B0 stepping too broken to run Windows/386, but that doesn’t say whether those steppings were fundamentally incapable of running Windows/386 or just too buggy for practical use.
Looking at the problem from another angle… Compaq’s CEMM does not appear to have any 386 stepping test, and obviously it relies on V86 mode (but not so much on 32-bit code). That might mean V86 mode worked on all 386 steppings… or just that Compaq only shipped 386 CPUs that had working V86 mode. Knowing the earliest stepping used in the Deskpro 386 would help.