AMD's Zen 6 will adopt Intel's FRED to modernize x86 interrupt handling

Skye Jacobs

Posts: 1,913   +58
Staff
Forward-looking: When AMD releases its Zen 6 processors, the company won't simply iterate on Zen 5 – it will introduce a fundamentally new CPU core architecture, shedding decades of legacy baggage embedded in the x86 platform. One of the most significant changes in this redesign is AMD's adoption of Intel's Flexible Return and Event Delivery (FRED) instructions, a modern replacement for a system mechanism that has been part of PCs since the early 1980s.

Every time a computer receives a network packet, completes a disk write, or a user moves the mouse, the processor handles an event known as an interrupt – a low-level signal that requires switching between user code and system code. For more than four decades, this process has been managed by the Interrupt Descriptor Table (IDT), first introduced with Intel's 80286 processor. Despite countless CPU generations, the fundamental way interrupts are handled has changed very little.

FRED aims to modernize this outdated foundation. Instead of forcing programmers to juggle multiple steps and ring-level transitions for each interrupt, FRED processes them in a single, atomic operation. This results in a cleaner, more reliable handoff between user and kernel code, reducing the risk of race conditions and inconsistent states when multiple events occur simultaneously.

AMD's adoption of FRED is part of a broader collaboration between AMD and Intel to align their work on the x86 architecture. Both companies are members of the x86 Ecosystem Advisory Group, a partnership announced in 2023 to ensure a unified instruction set across both vendors.

A year into that alliance, AMD confirmed that Zen 6 would incorporate FRED, following Intel's upcoming Nova Lake and Panther Lake platforms. While no current CPUs support the feature, its simultaneous rollout across both ecosystems marks an unusually coordinated shift in the historically fragmented x86 landscape.

This transition was not guaranteed. AMD had developed its own mechanism, Supervisor Entry Extensions (SEE), as an incremental workaround that preserved compatibility with older software. Industry consensus, however, favored Intel's cleaner, full-scale replacement.

Even Linux creator Linus Torvalds endorsed Intel's approach in a forum post, calling it a more complete solution that eliminates long-standing architectural cruft.

From a technical perspective, FRED simplifies CPU privilege handling by reducing it to just two levels – ring 0 for kernel code and ring 3 for user code. This streamlining not only removes layers of complexity for developers but also reduces CPU cycles spent on event handling. The practical result is improved performance and lower latency for workloads that generate a high volume of interrupts, such as network-intensive processes, high-refresh-rate gaming, and audio processing pipelines.

The performance gains may be even more pronounced in virtualization environments, where event handling often passes through multiple layers of software. Fewer transitions between privilege levels translate directly into reduced overhead and faster context switching – long-standing challenges in x86-based hypervisors.

Software support for FRED has already started appearing in major platforms. The Linux kernel has included preliminary FRED support since version 6.9, and future Windows releases are expected to implement it as well. Because only operating systems and low-level drivers interact directly with these instructions, end users are unlikely to notice any visible difference – but developers and system maintainers will.

Image credit: Fritzchens Fritz

Permalink to story:

 
So I guess Intel isn’t completely lacking in ingenuity after all… hope they compete better on the CPU side so we can see some better pricing…
 
Actually this sound really cool.
I wonder if they can pull it off effectively.
We will just have to wait and see I guess.
 
It'd be nice to think the NMI, and anything similarly non-maskable, has been taken out and shot too. There's nothing more buggy than disorderly interrupts.
 
X86 shedding legacy baggage is the most optimistic sentence I’ve ever read. This architecture is basically a hoarder house of backwards compatibility. Every time they clean one corner, they find another 1983 interrupt table hiding underneath.
 
Okay but what happens to all the old x86 software that still runs on todays hardware. Will it still work?
The last sentence in the article answers that question for you:
Because only operating systems and low-level drivers interact directly with these instructions, end users are unlikely to notice any visible difference – but developers and system maintainers will.
There will likely be some early incompatibility issues, and ancient legacy drivers may stop working altogether, depending on how they were coded (and if anyone even wants to attempt a conversion or alternative driver build). But regular users likely won't even notice anything changed. Other than maybe getting better performance that is...
 
X86 shedding legacy baggage is the most optimistic sentence I’ve ever read. This architecture is basically a hoarder house of backwards compatibility. Every time they clean one corner, they find another 1983 interrupt table hiding underneath.
Yet despite all that baggage, x86 still dominates HPC and panther lake is coming out swinging with ARM like efficiency.

x86, the gift that keeps on giving!
 
X86 shedding legacy baggage is the most optimistic sentence I’ve ever read. This architecture is basically a hoarder house of backwards compatibility. Every time they clean one corner, they find another 1983 interrupt table hiding underneath.
Yeah, Kinda sounds like Windows. Sort of.
 
... the processor handles an event known as an interrupt – a low-level signal that requires switching between user code and system code. For more than four decades, this process has been managed by the Interrupt Descriptor Table (IDT), first introduced with Intel's 80286 processor.
IDT was introduced with 80286 as a part of Protected mode.
Allowing to put list of interrupt handlers anywhere in memory and not accessible from user level / ring3 code.

But Interrupts were handled before 80286 came. Interrupt table had its fixed place. First 256 addresses in memory. Which was the reason why writing into memory using non-initialised pointer has so severe results.
INT0 was used for NMI (non-maskable interrupt) .. sitting at 0000:0000.
Keyboard, mice, other I/O devices had their routines linked to # of INT line.
Instruction Int 21[/] was used to call services of D.O.S.
 
The last sentence in the article answers that question for you:

There will likely be some early incompatibility issues, and ancient legacy drivers may stop working altogether, depending on how they were coded (and if anyone even wants to attempt a conversion or alternative driver build). But regular users likely won't even notice anything changed. Other than maybe getting better performance that is...
[SuperChicken] FRED, you knew the job was dangerous when you took it.
 
But, I thought Intel was dead? What gives? And, AMD? How yesterday. Thought the world belonged to Nvidia. Down wit CPUs; up with GPUs, right? Where's my coke?
 
Everyone seems to be missing the bigger news here:

FRED support will be coming (presumably) only to Win 11.
I assume these new CPU's will still be able to use IDT as a fallback on Win 10 and older, but unless MS enables FRED for Win 10 then the older OS will be at a disadvantage in terms of performance.
 
Linux will use it too.
At least with Linux you can choose to use the newer 6.9 kernel with an older OS.
On Windows there is no such modularity. Besides Unlike Windows I doubt there's too much pushback to newer kernels as there are to newer Windows versions.
 
Back