AMD adopts FRED together with Intel for Zen 6 architecture — replacement for decades-old IDT can improve performance and stability

AMD appears to be fundamentally redesigning its CPU architecture for the upcoming Zen 6 chips, rather than making it a subset of Zen 5. As a part of those improvements, thanks to X user InstLatX64, we now know that AMD has finally adopted Intel's FRED instructions for its new silicon, along with fresh matrix multiplication and bit reversal instructions.

FRED is a wholesale replacement of the 80286-era Interrupt Descriptor Table (IDT) mechanism that's well over 40 years old by now. The IDT is currently the standard way to handle system events, like a network packet being delivered or mouse input, and passing its data to a driver or application.

AMD's adoption of FRED is the result of both companies creating the x86 Ecosystem Advisory Group to coordinate work on the new instruction set. Last October, one year after the alliance's inception, AMD agreed to implement FRED on its upcoming chips. At this moment, no production chips from either company support FRED, though it's a reasonable expectation that Intel Nova and Panther Lake, and AMD Zen 6, will be the first lineups to do so.

Things looked a little shaky on the interoperability front for a little while, as AMD had its Supervisor Entry Extensions (SEE). While Intel's FRED is a full and complete replacement of IDT, AMD SEE can best be described as a viable workaround that requires as few changes as possible to legacy software.

Linus Torvalds himself clearly outlined his opinion in a forum post, hoping that both vendors would implement both ideas, but praising Intel's approach as a more complete clean-room solution that gets rid of legacy cruft entirely.

Regarding software support, the Linux kernel has had provisional support for FRED since version 6.9. Once again, it's reasonable enough to expect that whichever version of desktop or server Windows comes next will also have the feature enabled. Note that only low-level software like operating systems and drivers can use the feature; it's not a concern for actual applications.

As to what FRED actually is, we can offer an oversimplification. A system event (say, getting an incoming network packet) is called an interrupt and the data and/or code transfer for handling involve a ring transition. This scenario happens constantly in any operating system, across every part, from storage I/O (a write being complete) to mouse input (say, a simple click).

Until now, programmers had to rely on IDT, for which the accurate technical adjectives are hacky and janky. IDT enabled only a half-assed transition from kernel code to application code, meaning programmers had to perform many other operations manually, be careful about edge cases, think about multiple ring levels, and work around potential race conditions (where two system events happen simultaneously and step over each other).

FRED improves on all fronts by providing one-shot instructions to guarantee a clean transition from kernel to application and back, with a consistent stack (the information about the event and where to continue execution). The main FRED instructions are atomic, meaning they execute all at once (or not at all), so programmers don't have to worry about an inconsistent state when they need to handle an interrupt. There's far less mental overhead, too, as there is much less to think about. Even the old ring levels are gone, being reduced to 0 (kernel) and 3 (user).

All told, this means that developers can just call on FRED and it'll do all the necessary work for them in one sitting, and no longer have to code their way around a lot of corner cases and theoretical issues. This should enable more stable kernels, system drivers, bootloaders, and other low-level software.

At least in theory, FRED is also bound to improve overall system performance, as it consumes fewer CPU cycles, resulting in lower event latency. These can add up under high load scenarios, like handling large network transfers, and perhaps even high-refresh-rate gaming and audio work — though potential uplifts will vary for each type of workload.

FRED will definitely be a performance boon for virtualization scenarios that have particularly involved event handling passing through multiple layers. The x86 architecture has long been criticized for holding on to legacy features for far too long, so it's good news that FRED is arriving soon.

Follow 3DTested on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.