Windows NT stopped supporting the Intel 80386 processor with Windows 4.0, which raised the minimum requirements to an Intel 80486. Therefore, the Intel 80386 technically falls into the category of “processor that Windows once supported but no longer does.” This series focuses on the portion of the x86 instruction set available on an 80386, although I will make notes about future extensions in a special chapter.
[…]As with all the processor retrospective series, I’m going to focus on how Windows NT used the Intel 80386 in user mode because the original audience for all of these discussions was user-mode developers trying to get up to speed debugging their programs. Normally, this means that I omit instructions that you are unlikely to see in compiler-generated code. However, I’ll set aside a day to cover some of the legacy instructions that are functional but not used in practice.
Written by Raymond Chen, so you know it’s good stuff. Part 2, part 3, and part 4 are also already available.
8008 <- 8080 <- 8086 <- 80186 <- 80286 <- 80386 <- Pentium <- P6 <-AMD64
When people talk about how brain dead the x86 architecture is, it's important to remember that in 1972 when the 8008 was released, it was far from brain dead, and instead quite advanced. Every subsequent chip was compatible with the previous generation (the 8080 was merely source compatible with the 8008). All subsequent designs have to operate within the constraints of compatibility.
We're getting close to 50 years of compatibility.
Yet Windows x64 doesn’t run 16 bits code anymore (beside emulation), hence the “50 years of compatibility” is somewhat broken in a certain way. Yes, you can still install a 32 bits version that have the ability to run 16 bits code, but in the end, some things are ditched out. Microsoft doesn’t support Kaby Lake and older architectures, Linux dropped 32 bits support, etc… But sure, you still have the possibility to run bare to the metal real code. Provided you still have bios emulation.
“Linux dropped 32 bits support”
Unlikely.
You might be misremembering recent news about Linux devs considering dropping x32 – this is not the same as 32-bit x86.
This are not as they seem, of course.
Modern x86 CPUs actually contain RISC cores inside:
https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors
Yet the higher level instruction set is still compatible (and can be updated with bugfixes via BIOS during boot time). Intel tried multiple times to overcome this.
Intel first tried i860/i960 as an alternative RISC CPU. In fact, Windows NT was initially built on these system (the NT kernel design is an interesting, but off topic discussion). They gave up, when Pentium solved the issue (by internally translating CISC -> RISC).
Then they tried again with the Itanium/IA-64 design. That also failed — big time — against the simpler upgrade path offered by AMD. The amd64 instruction set provided reasonable extension of the existing 32 bit ones (albeit forfeiting 16 bit support). And backwards compatibility won once again. (Intel licensed the design, and uses it as EM64T, now both are just called x64).
Even when they introduce vastly different designs (SSE, AVX for SIMD instructions), they stayed in the x86 umbrella.
The only thing that can replace x86 instruction set at this point would be ARM being able to scale up. Even Intel was unable to move on, despite trying to do so multiple times.
sukru,
Indeed. The dominance of windows software on desktops has kept x86 processors in demand. Not for lack of trying, but neither microsoft nor intel have been especially successful at x86 alternatives. In a way, they’re victims of their own success in that they can’t compete with their own cash cows. It’s a chicken and egg problem. No developers care to support alternatives with so little marketshare, few users are interested in platforms with so little software support. Even when they offer x86 emulation to fill the gap, it’s generally a worse experience. Linux can make the jump to alternative architectures much easier and has had usable ARM distros for a long time, however linux is still a black sheep on desktops so it’s influence has been limited.
ARM’s primary growth has been in new markets and it’s built a stronghold in mobile. Time will tell if they’re able to displace desktops with mobile apps that are scaled up to larger screens and keyboards. Already my bank treats desktop users as second class citizens and coerces us to use IOS+android instead, not because they’re better but because they just stopped supporting the desktop. They even replaced their superior desktop website with a much worse mobile one. This is a regression to productivity as far as I’m concerned. Alas if enough providers similarly drop support for traditional desktop software in the future it will deal a huge blow to wintel and ARM has a lot to gain by it.
Ironically I’ve got mixed feelings about this since although I’d like to see more ARM hardware competition for the desktop I also have strong reservations about the way it could end up happening by replacing desktop software with mobile software….ugh.
Though vast majority of Chromebooks are still x86 – so evidently, also for Linux laptops, x86 CPUs offer something that current ARM chips don’t…
zima,
ARM has a large DIY following, which is fine for what it is, but it’s difficult to find ARM systems that fit my needs: upgradable memory, a raid array, discrete GPU, etc. Some large datacenters are evaluating custom built ARM systems, but there aren’t too many commodity options for average joes who just want to build a ARM system as they would a PC. I’ve purchased some ARM boards to evaluate myself, but I’m not a system builder and they’re not production ready. All of the high power ARM SBC I have suffer from overheating. I bought an Odroid computer with the hopes that it’s humongous heatsink would rectify it, but alas when I run it 24×7 I have to have an external fan blowing on it.
I don’t blame the ARM processors themselves, they run fine, but an equivalent x86 PC would have large heatsinks and system fans, etc. For whatever reason ARM manufactures haven’t made strong offerings for ARM PCs with expandable peripherals and good cooling. They’re too focused on the mobile market, and though I concede that I represent a tiny fragment of the market, I still wish there would be more production-ready desktop/server quality ARM hardware.
For the record, the Pentium was still thoroughly CISC.
It was the P6 core, starting with the Pentium Pro, that had several instructions executed as small uOps on a RISC core, modifiable via microcode updates.
Too bad AMD didn’t force Intel to use “amd64” name for the architecture, it would be poetic.
x86 goes back even further: https://en.wikipedia.org/wiki/Datapoint_2200