Quietly, both AMD and Intel have decided it's time to finally clean up some truly ancient and funky CPU design choices, which date all the way back to the early 1980s' 80286 architecture. They're going separate ways, and Linus Torvalds, Linux's founder, recently shared his thoughts on their CPU design choices.
AMD was the first to come out with its proposed changes in February 2021: AMD Supervisor Entry Extensions. Intel followed in March with its flexible return and event delivery (FRED) design. What sparked Torvald's interest was when someone on the Real World Technologies deep technology conversation forum introduced the topic with the note: "x86 - why unite when you can fragment?"
Torvalds, however, doesn't see it that way. He wrote:
Honestly, it doesn't look too bad.
The AMD version is essentially "Fix known bugs in the exception handling definition."
The Intel version is basically "Yeah, the protected mode 80286 exception handling was bad, then 386 made it odder with the 32-bit extensions, and then syscall/sysenter made everything worse, and then the x86-64 extensions introduced even more problems. So let's add a mode bit where all the crap goes away."
In contrast, the AMD one is basically a minimal effort to fix actual fundamental problems with all that legacy-induced crap that is nasty to work around and that has caused issues.
So, what are these problems? They are hidden with the x86's architecture's Interrupt Descriptor Table (IDT). This is a data structure that implements an interrupt vector table. It comes, unfortunately, with numerous exception problems.
These, according to Torvalds, include:
- IDT itself is a horrible nasty format and you shouldn't have to parse memory in odd ways to handle exceptions. It was fundamentally bad from the 80286 beginnings, it got a tiny bit harder to parse for 32-bit, and it arguably got much worse in x86-64.
- The %rsp general-purpose register is not being restored properly by return-to-user mode.
- Delayed debug traps into supervisor mode.
- Several bad exception nesting problems: Non-Maskable Interrupts (NMI), machine checks, and STI-shadow handling at the very least).
- Various atomicity problems with gsbase (swapgs) and stack pointer switching
- Several different exception stack layouts, and literally hundreds of different entry points for exceptions, interrupts and system calls (and that's not even counting the call gates that nobody should use in the first place).
Torvalds concluded: "But I suspect I forgot some." In short, it's a mess and it's been getting messier for some time.
So, what do both attempts to fix these problems bring to the table?
Torvalds thinks, "AMD aims to fix the outright historical bugs (b)-(e), but keeps things otherwise the same (ie it adds a bit more code to the microcode that basically replaces some of the horrible hacks you currently have to do -- badly -- in system software)." While, Intel recognizes "that there was more wrong than just the outright bugs that had to be worked around by system software, and introduces a 'fixed exceptions' model, which basically fixes all of the above."
He sees positive things about both models. Torvalds thinks the AMD paper "looks like a quick 'we haven't even finished thinking all the details through, but we know these parts were broken, so we might as well release this.'"
Intel FRED has had more work put into it. And Torvalds thinks, it's "the right thing to do. It really relegates the whole IDT to a 'we don't even use this at all, unless you have legacy segment selectors.' Good riddance to a truly horrid thing that goes back to a truly disgusting CPU architecture: The 80286."
Torvalds hopes in the long run AMD and Intel adopt both approaches. Why? Because, "The AMD version is better if you are an OS vendor that wants to change as little as humanly possible at the OS level, and get rid of known problems. Think 'legacy OS that we can't really make big changes to." While, "the Intel version is better if you think that x86-64 should actually survive longer-term, and you actually want to improve exception handling and speed things up actually takes you a good step in that direction."
Even if AMD and Intel don't end up adopting both, Torvalds suspects, "It's not exceptionally (pun intended) hard to just support both." After all, Torvalds concluded, "Fred is very clearly defined to have an entirely new model, and any OS vendor that goes that way will still have to support the legacy exception model for older CPUs."
In the real world, we're still a few years away from seeing chips rolling out of the silicon foundries supporting either Supervisor Entry Extensions or FRED. But, come the day they do, both will make life much easier for operating system kernel programmers and all other developers working at their computers' chip level.