4 ms·
As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is
by Macha 4y ago
As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture. Sure Intel could easily add support to GRUB and push Microsoft to do it for new Windows media, but that won't help the existing install base. Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them.
Plus I'm sure there's crazy DRM rootkits that depend on these implementation details.
Also, AMD has experimented with not-quite-PC-compatible x86 setups already in the consoles. As the fail0verflow talk about Linux on PS4 emphasised, the PS4 is x86, but not a PC. So despite building a x86 CPU with some less legacy, AMD didn't seem to think it worthwhile bringing it to a more general purpose platform
Also AMD/Intel/VIA are the only companies with the licenses to produce x86, and you'd need both Intel and AMD to sign off on licensing x64 to someone new.
- messe 4y ago> As the article points out, modern x86 CPUs boot up in 16 bit mode, then get transferred into 32 bit mode, then 64 bit mode. So right out the gate such a CPU is not compatible with existing operating systems, so now you have a non-compatible architecture Except that a modern OS is booted in UEFI mode meaning that the steps of going fro 16 -> 32 -> 64-bit mode are all handled by the firmware, not the kernel or the bootloader. The OS kernel will only (at most) switch to 32-bit compatibility mode (a submode of long-mode not protected mode) when it needs to run 32-bit apps, otherwise staying in 64-bit mode 100% of the time.
- anyfoo 4y agoYeah. Long mode is a bit of a line in the sand, leaving many features behind that were kept for compatibility (segmentation, vm86...). It came at a time where, fortunately, the mainstream OSes had enough abstraction so that software did not have to be written for what effectively was the bare metal anymore, with DOS almost being more of a "software bootloader with filesystem services".
- anyfoo 4y ago> Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. That may be only secondary, though. Itanium simply failed to deliver performance promises and be competitive. The compiler was supposed to effectively perform instruction scheduling itself, and writing such a compiler turned out more difficult than anticipated.
- FullyFunctional 4y agoI've see this a lot, but IMO the truth is slightly different: the assumption behind EPIC was that a compiler _could_ do the scheduling which turned out to be _impossible_. The EPIC effort roots goes way back, but still I don't understand how they failed to foresee the ever growing tower of caches which unavoidably leads to a crazy wide latency range for loads (3-400+ cycles) which in turn is why we now have these very deep OoO machines. (Tachyum's Prodigy appears to be repeating the EPIC mistake with very limited but undisclosed reordering). OoO EPIC has been suggested (I recall an old comp.arch posting by an Intel architect) but never got green-lit. I assume they had bet so much on compiler assumption that the complexity would have killed it. It's really a shame because EPIC did get _some_ things right. The compiler absolutely can make the front-end life easier by making dependences more explicit (though I would do it differently) and by making control transfers much easier to deal with (the 128-bit block alone saves 4 bits in all BTB entries, etc). On the balance, IA-64 was a committee-designed train wreck, piling on way too much complexity, and failed both as a brainiac and speed-daemon. Disclaimer: I have an Itanic space heater than I occasionally boot up for the chuckle - and then shuts down before the hearing damage gets permanent.
- klelatti 4y agoThis is really interesting. Any recommendations for further reading on EPIC and related technologies?
- FullyFunctional 4y agoIn practice EPIC = IA-64 and Itanium is the only implementation, but IA-64 is probably the easier thing to search for. The only book I have is “IA-64 and Elementary Functions: Speed and Precision”. EPIC’s problem is shared with VLIW of which EPIC can be understood as a refinement. VLIW excels in a deterministic world where the compiler can predict latencies and produce a good schedule, but falls apart in face of loads with highly variable latencies (an in-order implementation has no option but to stall when load data doesn’t arrive on time). EPIC patches this a bit by allowing software prefetching and SW exposed speculation, but it comes at a significant code bloat and it can cover only a small fraction of what dynamic scheduling can cover. At Transmeta, our VLIW engine did this too (with some obvious advantages over IA-64) and we suffered from similar problems.
- klelatti 4y ago> Intel tried launching a non-compatible CPU once, it was Itanium, it didn't go so well for them. More than once. iAPX432 if anything went worse.
- anyfoo 4y agoYeah, but that, again, was for far worse reasons than just not being "compatible". In fact, iAPX432 was exceptionally bad. Intel's i960 for example fared much better in the embedded space (where PC-compatibility did not matter).
- klelatti 4y agoIndeed and I suppose in fairness I don’t think 432 was ever intended as a PC cpu replacement whilst Itanium was designed to replace some x86 servers. As an aside I’m still astonished that 432 and Itanium got as far as they did with so much cash spent on them before without conclusive proof that performance would be competitive. Seems like a prerequisite for projects of this size.
- deleted 4y ago[deleted]