Those who have worked on a hobby operating system for x86 will have interacted with its rather complex and confusing interrupt model. [Evalyn] shows us why and how to use Flexible Return and Event Delivery (FRED), a new standard by the x86 Ecosystem Advisory Group.
Of course, it would be silly to omit the fact that Linux received patches first. But that isn’t the interesting part; after all, Linux is often the first place to have support for this kind of thing. No, what’s interesting is [Evalyn]’s implementation, to our knowledge among — if not the first — non-Linux operating system to support it.
To know why we should switch to FRED, we must first understand what it replaces. The Interrupt Descriptor Table (IDT) tells the CPU what code to run when certain interrupts or faults happen. The big problem that the IDT has is inconsistency, most egregiously the fact that the stack layout depends on which interrupt happened. To solve the issues with the IDT, FRED was created.
[Evalyn] shows us the process, starting at the documentation, then finding an emulator capable of it and culminating in a demo where DOOM runs in EvalynOS with FRED enabled.
Pentium II die shot. Martijn Boer, Public domain.
I like the concept but I have this deep suspicion that Intel who wrote the standard has specifically crafted to benefit Intel’s chips. I’m not saying FRED isn’t a good idea, I simply don’t believe it should be blindly implemented using the precise scheme that Intel has presented without an extremely detailed comparative analysis of performance.
Seems to just be a cleaner mechanism. Interrupts are handled in microcode so shouldn’t be a problem for AMD as a cleaner mechanism means less complicated code, and most likely better performance.
The upcoming AMD Zen-6 CPU will have FRED.
And the ‘x86 Ecosystem Advisory Group’ is a collaboration between Intel and AMD.
I suspect there is a unified spec, seeing that is the purpose of such a collaboration right?
Talking of specs, I read that for compatibility with Zen-6, AMD motherboards should really have a ROM of 64MB, so that they can support all AMD AM5 CPU.
I guess with 32MB they have to choose which CPU’s they support in BIOS? Dunno.
If that is the case though they could maybe have several same version BIOS updates depending of which CPU a user has. But that would be messy and confusing to some.
Intel and AMD is not a “collaboration” but plane and simple duopoly that can enforce their prices, their decisions and their chips in any way they see fit to generate corporate profits. Until we see x86 PCs with RISC-V CPUs made by independent fabs I wouldn’t be so excited. Also, BIOS which used to be a simple and open standard that can be operated from Real Mode was now replaced by closed-source UEFI.
https://en.wikipedia.org/wiki/UEFI
https://libreboot.org/
https://github.com/tianocore/edk2
edit: about the duopoly i agree. But really, BIOS was never simple.
Isn’t that usually the case? Intel adds some new instructions, AMD follows. After Zen 4 and 5 got a better AVX512 implementation, Intel dropped it and coughed up AMX just to get ahead somewhere. :P
i definitely share your suspicions but AMD and Intel have been stealing eachother’s good ideas for ages, at least since amd64 became the defacto x86-64.
you know how China is always making brand new cities designed to be like New York or Venice? Why don’t they lay one out like the die of a Pentium II? It could have a bunch of parking lots on the west end of town with shuttle buses into the east end of town, where it is pedestrian-only
Page says 3 comments. Page shows no comments.
It says thoughts. Probably not written yet :)
Sigh. Comment reporting attack again. It’s Monday morning and I’m triaging it…
At first I thought this might be FRED “Flexible Recreational and Educational Device” which in 1970 was built as a prototype hobby computer using discrete logic chips. It later evolved into the (CDP1802 CPU) COSMAC ELF single-board computer published in Popular Electronics in August 1976. But I guess that’s going a little too far back. I guess there’s a distantly related “what if” exercise if RCA’s CDP1802 was the basis of PC CPU development rather than x86, but I’m going out on a limb to make that connection