<i>Suppose you want to support strings and have a string comparison instruction. You might think that &quot;it&#x27;s done in the hardware&quot;, so it&#x27;s blindingly fast. It isn&#x27;t, because the hardware still has to access memory, one word per cycle. A superscalar&#x2F;VLIW assembly loop would run just as quickly; the only thing you&#x27;d save is a few bytes for instruction encoding.</i><p>Actually if you&#x27;ve actually looked at things like SSE memory copying&#x2F;comparison routines, it&#x27;s not &quot;a few bytes&quot;, it&#x27;s more like a factor of 100x+. REP MOVSB is 2 bytes; a SSE memcpy, highly unrolled - incidentally, also a bad idea for modern CPUs - is easily a few hundred. I&#x27;ve seen ones over a kilobyte(!) The former is essentially the same speed as the latter, but makes for significantly less instruction cache utilisation, which is increasingly important today.<p><i>You see, RISC happened for a reason.</i><p>When memory bandwidth was not the bottleneck, it was a good idea. Now, not so much. Even ARMs which are considered &quot;RISC&quot; are growing into uop-decoding decoupled OoO machines like x86, and adding more instructions with each new generation. I like to mention this article, where the &quot;purest&quot; RISC, MIPS, turns out to be the least power-efficient:<p><a href="http:&#x2F;&#x2F;www.extremetech.com&#x2F;extreme&#x2F;188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient" rel="nofollow">http:&#x2F;&#x2F;www.extremetech.com&#x2F;extreme&#x2F;188396-the-final-isa-show...</a><p>I&#x27;d say that CPUs are certainly getting more high-level and CISCy, but not in the same way as their original proponents imagined. If you don&#x27;t think so, try beating POPCNT, CRC32, AESENC, etc. with a sequence of simpler instructions...