Why Intel can't seem to retire the x86

Despite three high profile efforts, Intel's attempts to replace the x86 have gone down in flames. In the process, x86 only grew stronger. Here's how.

intel_cpushack_0.jpgImage credit: CPUShack Museum

It's rare that technology can last multiple decades, but it does happen. Bob Metcalf invented Ethernet while working at Xerox PARC in the early 1970s and it still runs the Internet, TCP/IP was a DARPANet creation of the early '70s and sendmail, used in SMTP email routing, was created in 1979. So for all the modernity of technology, we're still using a lot of stuff that's middle-aged in human terms.

The x86 microarchitecture is another aged technology, and it has survived more assassination attempts than Fidel Castro. What makes the number of attempts on x86 more interesting is that Intel is the one who keeps trying to take it out. On at least three occasions, the company had what it thought was the successor to x86 and in all three cases it failed to one degree or another.

While those chips failed, x86 only got stronger in the process. Its fight with ARM may prove the greatest challenge ever, but for now it's still playing out. Let's take a look at those three would-be successors to x86.


It is possible to be too far ahead of your time, as the iAPX432 showed. It was ambitious and extremely complex, and a total failure. Begun in the mid-1970s and shown in 1981, iAXP was a multi-chip, 32-bit microprocessor referred to as a "MicroMainframe" or a "mainframe on a chip." It had a very advanced design that included garbage collection, built-in fault tolerance and support for object-oriented programming. It promised multiprocessing in clusters of up to 63 nodes.

And it was a disaster. At the same clock frequency as a 286, the 432 ran at one quarter the speed. Intel never even shipped it to the market. So what went wrong? Just about everything.

"I think they tried to do too much at the time, trying to integrate the latest and greatest out of universities that didn't lend itself to hardware at the time," says John Culver, owner of the CPUShack Museum and historian on all things CPU.

Martin Reynolds, a research fellow with Gartner, says the 432 comes from a concept called the semantic gap, where programmers noticed that they got the best code when the chip's instructions reflected the code they were writing. So if the instruction looked like Fortran or COBOL instructions, you got the best results.

"That's the idea behind the semantic gap, to make everyone speak the same language," says Reynolds. "They put in very high-level instructions so the gap between code and instructions were very short. That allowed programmers to do things very quickly." The problem is that along came the C language, which blew every other language out of the water and it ran terribly on the 432.

iAPX432 could have been Intel's Waterloo. All of its top talent was working on the processor. Fortunately, two junior engineers named John Crawford and Pat Gelsinger were working on a side project, turning the 16-bit 80286 into a 32-bit chip. Intel had their work – the 80386 – on which to fall back, and a good thing, too.

But the iAPX432 wasn't a waste of engineering time. Much of the multitasking and memory management features found their way into the 386 and 486 designs, and Intel would later bring a single-chip version of the 432 to market called the i960.

The i960 found its way into embedded systems and Intel sold it for almost 20 years as an embedded controller. "Most people consider the 960 to be a failed design because you didn't see it in a PC, but it didn't go out of production for 20 years," said Culver.


The i860 was Intel's first big stab at RISC processors (although it could be argued the 432 was a RISC chip). It came out in 1992, right around the same time Intel released the 486DX2, which featured an internal clock that was twice as fast as the CPU bus, a revolution for the time.

(Just to show you how things have changed, your CPU clock now is on average 22 to 30 times faster than the bus.)

But Intel ran into a few problems. For starters, the market wasn't sure which side Intel was on. Intel put both processors out there and let the market decide, and the market chose x86, the processor with what was by then a huge existing library of software. i860 was a whole new design with no software and it suffered from a chicken and egg problem all new processors face.

Then there was the fact that the RISC market really heated up in the '90s, with SGI's MIPS processor, DEC's Alpha, HP's PA-RISC and eventually IBM's Power all fighting it out.

In the end, the i860 was undone because the compilers couldn't fully optimize code for it, says Culver. "It had a niche success where code could be done very specifically, code that does one thing and does it very well. It was used in things like high speed image processing, almost DSP-like tasks. That's due to its design. It almost has an on-board graphics processor," he said.

1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon