4 ms·
The minimum requirements for a portable OS on 32 bit hardware really doesn't need to be anything more than: * 32 bit CPU * relatively recent toolchain support
by johnklos 1y ago
The minimum requirements for a portable OS on 32 bit hardware really doesn't need to be anything more than:
* 32 bit CPU
* relatively recent toolchain support
* MMU
* memory, storage, I/O
In the last couple of decades, we've added as a requirement:
* atomic operations
The i80386 didn't have atomic operations, so after gcc 4.1.2, the decision was made to drop i80386 support from gcc. Dropping i80386 from Linux simplified MP code because of the lack of these instructions.
But other than these requirements, what does the i80486 processor not do that newer processors do? People who don't know any better like to talk about the amount of maintenance and testing that's required to support an older processor, but I think most of those people are either repeating old tropes or are misattributing issues. Sure, cleaning up pre-PCI code is one thing, but attributing that to the i80486 is a little misleading.
Do people really sit around and worry about whether their code will compile and run on SuperH, for instance? Heck, no. So does that mean we can't have a modern OS running on SuperH systems without all this testing and maintenance? Well, maybe this "maintenance" is a bit of a myth, because not only do we have a modern OS, but we have many thousands of open source programs that compile and run on SuperH, even without their authors necessarily knowing that SuperH even exists.
My point is that there may be good reasons for a commercial focused kernel / OS to no longer support older CPUs, but let's not buy in to the handwavy BS they use to try to justify the changes. They can be honest and just say they want to clean up and remove things that don't have many users.
- sillywalk 1y ago> what does the i80486 processor not do that newer processors do TSC (time stamp counter) and CX8 (CMPXCHG8B) hardware support"[0][1] I don't know what these processor features actually do. Also from [0] it looks like it is also removing the floating point emulation code for CPUs without hardware floating point support e.g. 486-SX [0] https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@kernel.org/ https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@... [1] https://www.phoronix.com/news/Linux-RFC-Remove-i486-Early-586 https://www.phoronix.com/news/Linux-RFC-Remove-i486-Early-58...
- johnklos 1y agoYou're making my point for me, in a roundabout way. These are handwavy excuses, not valid reasons.
- dwattttt 1y agoThose are excuses, in the same way atomics weren't "needed"; cmpxchg is a hardware locked operation that's quite important for lockless algorithms.
- happymellon 1y ago> I don't know what these processor features actually do. I'm afraid saying it is missing a feature, but unable to say whether that feature is required for anything is what the gpp is complaining about and is an excuse not to support it. Now if the combobulator transactions with the injunction function to provide the higher level of precision required, then that could be an argument to deprecate the architecture.
- johnklos 1y agoWhich is why i80386 was dropped even though memory instructions could be prefixed with "LOCK" to make them atomic, so cmpxchg equivalent could be done. So dropping the i80386 wasn't necessary, and saying it was because of the lack of atomic instructions was an excuse, because the real reason was that they didn't want to keep i80386 atomics around.
- RetroTechie 1y agoMay I add: * People willing to do maintenance (testing, debugging, upstreaming patches etc). For a many-platform OS like Linux it's probably not that hard to keep an arch supported once the plumbing is in place. It's not like there's new 486 based IC's coming out regularly. But still... someone's gotta do it. I suspect much "supported" was already in the form of: platform-specific drivers in-tree, arch support in place, all that stuff compiled, done. But at the same time, if you'd take result & run it on real 486 hardware, expect loads of issues. Software in source format tends to bitrot after testing/use on physical hardware goes away. Binary, less so (but of course other issues there).