Intel And AMD Make X Less Of A Variable For X86 Processors

One of the oldest ideas in humanity – and one that may have predated language as we know it – is that the enemy of my enemy is my friend. Another adage is that he who has the gold makes the rules, and in the datacenter market these days, the Super 8 hyperscalers and cloud builders have all of the gold and they increasingly are setting the rules.

These are two of several reasons why, we think, that Intel and AMD – companies that do not usually refer to each other by name but simply say “our competitor” – are burying the hatchet and forming what they call the X86 Ecosystem Advisory Group to shape a collective and collaborative future for the X86 instruction set and the processors that use it.

While the ARM and RISC-V collectives have standard bearers that keep chip designers from wandering off and extending the instruction sets of these architectures in unique ways that break compatibility, the X86 architecture has had no such standard bearer because Intel was under the distinct impression that no one else should be allowed to clone its instruction set architecture or its processors. This is something that the courts eventually decided was not the case, which is why we need an X86 standard today.

Burying The Hatchet – And Not In Each Other’s Skulls

The history between Intel and AMD is long and bitter, and that makes the agreement today all the more remarkable. And is shows how a united front of X86 CPU makers against the Arm collective and the rising RISC-V tide is vital to the future of the X86 architecture. Besides, if there is one thing that neither AMD nor Intel want to do, it is make Arm processors. That said, we would not be surprised to see one of them – or both – shift to RISC-V at some point to counter Arm. IBM has System z mainframe motors and Power compute engines for different purposes and at very different price points.

The epic battles between Intel and AMD have gone on so long that it may seem strange to see these two companies work together on the X86 architecture, but as we say, we think the two are getting some encouragement from outsiders.

These include – but is certainly not limited to – the founding members of the X86 Ecosystem Advisory Group aside from AMD and Intel: Broadcom, Dell, Google, Hewlett Packard Enterprise, HP Inc, Lenovo, Meta Platforms, Microsoft, Oracle, and Red Hat (now part of IBM). Linus Torvalds, the creator of the Linux kernel and his own standard bearer and keeper, is also a member, and so is Tim Sweeney, the chief executive officer of Epic Games. We are pretty sure that Amazon Web Services and the Chinese hyperscalers and cloud builders Alibaba, Baidu, and Tencent have opinions here, too, but no one can look like they are giving Chinese companies any sway over US companies these days.

The point is, Intel and AMD need to act as if there is a standard, so they may as well create one together or their biggest customers will just move even more aggressively to Arm or start looking at RISC-V.

It all started out so civilly. In 1982, AMD became a second source manufacturer of Intel 8086 and 8088 processors so IBM would use the chip in its legendary Personal Computer, and it wasn’t long before the lawyers were called in. In 1991, AMD sued Intel on antitrust grounds and a jury not only awarded AMD $10 million but a royalty free license to the X86 architecture, which turns out to be a hell of a lot more valuable over the more than three decades since. There was a lot of back and forth in the courts, more lawsuits, and eventually AMD did a clean-slate implementation of the K5 architecture to truly and directly compete against Intel in PC and eventually server CPUs.

Intel was feeling particularly proprietary about the X86 architecture because it had been extending it for two decades at this point. Intel created the progenitor of the X86 architecture back in 1971 with the four-bit 4004 microprocessor, the first single chip, general purpose central processing unit, and one really intended for microcontrollers, not personal computers. This was followed by the 8-bit 8008, the 8080, and the 8085 chips over the next few years, which were aimed at PCs. The 16-bit 8086, with a whopping 29,000 transistors, that came out in 1978 is arguably the first true X86 processor as we know it today.

It is not a surprise that Intel wants to do everything possible to help the X86 architecture hold its datacenter ground against Arm and RISC-V. With Linux dominant for new workloads in the datacenter and supported well with Arm after a decade and a half of work, Intel cannot afford to have two different X86 architectures in the field and its own designs on the wrong side of any particular argument.

This is particularly true as Intel has added AMX math units to its most recent Xeon server processors and AMD has yet to add its own matrix or tensor cores to the Epyc CPUs, nut has added them to its Ryzen CPUs for client devices. AMD was a laggard with vector processing in its Ryzen and Epyc processors and has only recently offered full support for full-width 512-bit AVX-512 vector units in its server CPUs. The software stacks for HPC and AI could have come together quicker and easier if Intel and AMD agreed on how to do fat vectors ahead of time.

It is also helpful to remember that this X86 innovation is not a one-way street, with Intel always deciding. For example, it was AMD, and not Intel, that first delivered 64-bit memory and processing extensions to the X86 architecture in the datacenter back in the early 2000s with the Opterons. Intel was busy creating the Itanium architecture with Hewlett Packard and got way sidetracked, leaving the door open for Opteron to walk straight into the datacenter. And this time around, with the Epyc assault in the datacenter, Intel’s foundry delays over the past decade have given AMD a chance to perfect its chiplet designs and manufacturing processes with Taiwan Semiconductor Manufacturing Co. It is Intel that has been catching up again.

But rest assured, Intel will catch up and AMD will not lose focus and there will be a competitive market for legacy X86 processing, even if Arm does soon account for a quarter of server shipments and even half of server shipments someday. To hold that share, the X86 providers and the customers who buy a lot of server processors have to work together to keep the X86 architecture focused and competitive.

“The point of this is really to ensure that we are getting all the voices from our stakeholders – our customers, our key operating system and application vendors and folks that are really driving the future of the software – to ensure that we are mutually investing in as much consistent interface as possible to minimize those differences and merge them over time,” Forrest Norrod, general manager of the datacenter business at AMD, explained on a call ahead of the announcement at the Open Compute Project Summit 2024 where this X86 group was announced. “This, by the way, begins a journey. This is not going to be a situation of tomorrow all products will be compliant to one particular ISA. But the clear intent is to minimize differences and to unify the architecture over time.”

Intel seconded that motion, and specifically, by Justin Hotard, who ran the HPC business at Hewlett Packard Enterprise for a few years until joining Intel has general manager of its Data Center & AI group in February in the wake of the impending spinout of the Altera FPGA division.

“We are looking at new innovations in the architecture going forward so that we implement them in standard ways,” said Hotard. “We think that provides easier adoption for the entire ecosystem, whether they are hardware vendors or software developers. That’s part of what we want to address with the advisory group. There has been lots of different feature requests that we have had for X86. Some have been adopted by one of us. Some have been adopted by neither of us. With the agreement, we’re going to have a consistent approach that is foundational so we have good predictability.”

There are not a lot of specifics concerning what the big X86 customers want or what either Intel or AMD have cooking with their own changes and extensions to the X86 ISA. We see hints here and there. For one thing, only two weeks ago, Intel published a paper called Envisioning A Simplified Intel Architecture, introducing a stripped down architecture called X86S that get rid of legacy 16-bit and 32-bit backwards compatibility modes. Microsoft doesn’t even ship a 32-bit version of Windows or Windows Server anymore, and Intel firmware no longer supports 32-bit operating systems but 32-bit compiled applications can still run inside them in emulation mode. And 16-bit applications are no longer supported natively. So, why does the Xeon core need to do this?

It’s a fair point. And to be sure, there is probably some version of Windows NT Server doing some vital work somewhere that someone forgot about. We can’t stop progress for such users.

Both Norrod and Hotard were clear that AMD and Intel intend to be fierce competitors even as they agree on working together on architectural frameworks and interfaces. And as we pointed out on the call with them, the very different ways that Intel and AMD create cores, down to the gorpy bits of branch predictors, pipelines, and caches and the higher level packaging and interconnect choices both in the CPU package and across them, leaves plenty of room for differentiation between the two companies. There is no way this won’t continue. The difference now is that either company will not have to spend time reverse engineering some neat thing the other one has come up with. They can work together to define a shared architecture and then do their own implementations of new features.