I think there are a few other legitimate problems with x86 than decode complexity:<p>* x86_64 traditionally only has 16 registers and destructive instructions. This is apparently also a problem for Intel, hence, they introduced APX which goes to 32 GPR and adds three-operand instructions. But who will use APX in the next 10 years outside specialized server software and gentoo users? Consider that most applications still target x86-64-v1, and runtime dispatch isn't really practical for this.<p>* Piling on ever larger SIMD extensions. This is not so much a burden on the implementation, but on the software landscape. The way intel and AMD traditionally seem to implement SIMD instructions, is to have execution units that can do an operation of the largest SIMD width, and use those to also execute the smaller SIMD widths. That seems reasonable, and probably is a good tradeoff given the decode complexity, but it also means that not using the latest SIMD extension wastes a lot of compute power. If decode was easier, you could've stuck with one SIMD width, and just add more execution ports, which means that older software also gets a speedup on newer generations. This is kinda what AMD did for Zen 4, where they implemented AVX512 on top of AVX2, instead of the other way around. Or how ARM implementations that only support 128-bit wide NEON can keep up with AVX2 (256-bit) and sometimes AVX512 (512-bit).<p>* All the legacy things may not cost much in terms of die space, because they are implemented in microcode, but I'd imagine they have significant development and verification costs.<p>Edit:<p>Another aspect regarding decode complexity is that the latest ARM cores started removing the uop cache, this would be pretty much impossible for a fast x86 implementation. I wonder how ARM decode width - uop cache and x86 decode width + uop cache scale for wider and wider cores.
I got tired of the video because they never got to the point. Here’s the article:<p><a href="https://hackaday.com/2024/03/21/why-x86-needs-to-die/" rel="nofollow">https://hackaday.com/2024/03/21/why-x86-needs-to-die/</a><p>The article is, uh, well it’s bad. I’m a little hesitant to respond point-by-point to an article like this because it just sucks up so much time, and there’s just so much wrong with the article on so many levels. Here’s the response article:<p><a href="https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to-die/" rel="nofollow">https://chipsandcheese.com/2024/03/27/why-x86-doesnt-need-to...</a><p>The video appears to go into detail about things like how pipelines but it’s a long video that just doesn’t get to the point fast enough. I think the video is somewhat tearing into the article and ripping it apart, but I hear some comments in the video which I think are not that great, like at 1:01:25:<p>> RISC is reduced instruction set computer, just means not very many instructions<p>RISC is better understood not in terms of the acronym itself, but as a label for the way CPUs were designed post 1980 or so.