Note that the post seems to be discussing about the old-school RISC reasoning, more than what we consider "RISC" in the modern world. Now RISC is just a style o

Note that the post seems to be discussing about the old-school RISC reasoning, more than what we consider "RISC" in the modern world. Now RISC is just a style of ISA (and/or more informally some description of some internal aspects of pipelines of CPUs (regardless of the ISA), behind the decoder and register renaming - and even then that's very far from all aspects)). And btw just because an instruction is called “Floating-point Javascript Convert to Signed fixed-point" with "Javascript" in its name does not disqualify it for appearing in a "RISC" ISA (or even an old-school RISC uarch). At all. The (proven) modern high perf microarchitecture for generalists CPUs is pretty much the same for everybody nowadays (well some details vary of course, but the big picture is the same for everybody), so a RISC ISA is not necessarily very interesting anymore, but also not necessarily a big problem. However if we take things that still can have in impact on the internals, I would prefer RMW atomic instructions to LL/SC most of the time (arguably LL/SC is the "RISC" way to go). Hell I would even sometimes want posted atomics... So back to the topic: if RISC is to be interpreted as microcode like/near programming, yeah the RISC approach failed for state of the art high perf in the long run, and it even was a very long time ago that it did -- but was it even thought by anybody that it would win? Not so sure. It was more a nice design point for another era, that only lasted a few years. Anyway the term has become overloaded a lot, and has produced crucial results, even if indirectly. And I agree a lot with the opinion that Skylake/Zen-like uarch is the way to go, and even VLIW is dubious (or even already known as a failure if we take Itanium as the main example) -- I don't even think the Web or anything can save it, to be honest. But conflating CISC with the presence of an instruction useful for Javascript is nowhere near the right interpretation of the term "RISC", regardless which is chosen. I mean at a point you absolutely can have a wide variety of execution units, without that disqualifying your from having the main "RISC" aspects.