<story><title>ARM or x86? ISA Doesn’t Matter (2021)</title><url>https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/</url></story><parent_chain><item><author>codedokode</author><text>x86 also uses 2-address instructions which means that you often need to use moves between registers (additional instructions), example: [1]. ARM uses 3-address instructions.&lt;p&gt;Also, x86 code is compact, but not as compact as in era of 8080 [2]   - here addition and multiplication require 3 bytes each, 6 bytes total. To my surprise, ARM has an add-multiply instruction and it uses just 4 bytes (instead of 8) [3].&lt;p&gt;And RISC-V uses 6 bytes because of shortened instruction for addition [4]&lt;p&gt;Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser.&lt;p&gt;Also to my great disappoitment none of those CPUs has checked overflow for arithmetic operation.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jsoccE5jv&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jsoccE5jv&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jTMs1MEzh&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jTMs1MEzh&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;nGb8qKcxe&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;nGb8qKcxe&lt;/a&gt;&lt;p&gt;[4] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;x9c115crY&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;x9c115crY&lt;/a&gt;</text></item><item><author>ip26</author><text>It&amp;#x27;s a trade-off between problems. Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instructions decrease code density, which asks more of the instruction cache. Note Zen4 has a 32 KB L1 instruction cache while the M1 has a 192 KB L1 instruction cache, requiring extra cleverness here instead to handle the higher latency and area. Meanwhile, micro-op caches hide both problems.&lt;p&gt;The are ripple effects to consider as well. The large L1 caches of M1 (320 KB total) put capacity pressure on L2, towards larger sizes and&amp;#x2F;or away from inclusive policy. See the 12MB shared L2. Meanwhile, the narrower decode of Zen4 puts pressure on things like branch prediction accuracy &amp;amp; mispredict correction latency - if you predicted the wrong codepath, you can&amp;#x27;t catch up as quickly. See the large branch predictors on Zen4.</text></item><item><author>tux3</author><text>The x86 decoders consume a reasonable amount of power, but the trouble is making them wider without affecting that.&lt;p&gt;I have an AMD CPU. Zen CPUs come with a fairly wide backend. But the frontend is what it is (especially early Zen), and without SMT it&amp;#x27;s essentially impossible to keep all those execution units fed.
It&amp;#x27;s not that 8 x86 decoders wouldn&amp;#x27;t be a benefit, it&amp;#x27;s just that more decoders isn&amp;#x27;t cheap in x86 cores, each extra decoder is a serious cost.&lt;p&gt;If you compare with the big ARM cores, having a wide frontend is not a complex research problem or an impractical cost. 8 wide ARM decode is completely practical. You even have open source superscalar RISC-V cores just publicly available on Github running on FPGAs with 8 wide decode.
Large frontends are (relatively) cheap and easy, if you&amp;#x27;re not x86.&lt;p&gt;So when we notice that the narrower x86 CPU&amp;#x27;s decode doesn&amp;#x27;t consume that much (a &amp;quot;drop in the ocean&amp;quot;), that&amp;#x27;s because it was designed narrower to keep the PPA reasonable! The reason I can&amp;#x27;t feed my Zen backend isn&amp;#x27;t because having a wide frontend is useless and I should just enable SMT anyways, it&amp;#x27;s because x86 makes wide decodes much less practical than competing architectures.</text></item></parent_chain><comment><author>userbinator</author><text>&lt;i&gt;Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser.&lt;/i&gt;&lt;p&gt;Look at the demoscene for an example of dense x86 code, especially in the sub-1K categories. They routinely achieve code densities for x86 that no compilers I know of can get close to, and AFAIK I have not seen the same happen with ARM, nor MIPS or any other well-known RISC.&lt;p&gt;3-address instructions improve code density only in situations where &lt;i&gt;both&lt;/i&gt; source operands are needed later.</text></comment>
<story><title>ARM or x86? ISA Doesn’t Matter (2021)</title><url>https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/</url></story><parent_chain><item><author>codedokode</author><text>x86 also uses 2-address instructions which means that you often need to use moves between registers (additional instructions), example: [1]. ARM uses 3-address instructions.&lt;p&gt;Also, x86 code is compact, but not as compact as in era of 8080 [2]   - here addition and multiplication require 3 bytes each, 6 bytes total. To my surprise, ARM has an add-multiply instruction and it uses just 4 bytes (instead of 8) [3].&lt;p&gt;And RISC-V uses 6 bytes because of shortened instruction for addition [4]&lt;p&gt;Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser.&lt;p&gt;Also to my great disappoitment none of those CPUs has checked overflow for arithmetic operation.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jsoccE5jv&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jsoccE5jv&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jTMs1MEzh&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;jTMs1MEzh&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;nGb8qKcxe&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;nGb8qKcxe&lt;/a&gt;&lt;p&gt;[4] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;x9c115crY&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;godbolt.org&amp;#x2F;z&amp;#x2F;x9c115crY&lt;/a&gt;</text></item><item><author>ip26</author><text>It&amp;#x27;s a trade-off between problems. Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instructions decrease code density, which asks more of the instruction cache. Note Zen4 has a 32 KB L1 instruction cache while the M1 has a 192 KB L1 instruction cache, requiring extra cleverness here instead to handle the higher latency and area. Meanwhile, micro-op caches hide both problems.&lt;p&gt;The are ripple effects to consider as well. The large L1 caches of M1 (320 KB total) put capacity pressure on L2, towards larger sizes and&amp;#x2F;or away from inclusive policy. See the 12MB shared L2. Meanwhile, the narrower decode of Zen4 puts pressure on things like branch prediction accuracy &amp;amp; mispredict correction latency - if you predicted the wrong codepath, you can&amp;#x27;t catch up as quickly. See the large branch predictors on Zen4.</text></item><item><author>tux3</author><text>The x86 decoders consume a reasonable amount of power, but the trouble is making them wider without affecting that.&lt;p&gt;I have an AMD CPU. Zen CPUs come with a fairly wide backend. But the frontend is what it is (especially early Zen), and without SMT it&amp;#x27;s essentially impossible to keep all those execution units fed.
It&amp;#x27;s not that 8 x86 decoders wouldn&amp;#x27;t be a benefit, it&amp;#x27;s just that more decoders isn&amp;#x27;t cheap in x86 cores, each extra decoder is a serious cost.&lt;p&gt;If you compare with the big ARM cores, having a wide frontend is not a complex research problem or an impractical cost. 8 wide ARM decode is completely practical. You even have open source superscalar RISC-V cores just publicly available on Github running on FPGAs with 8 wide decode.
Large frontends are (relatively) cheap and easy, if you&amp;#x27;re not x86.&lt;p&gt;So when we notice that the narrower x86 CPU&amp;#x27;s decode doesn&amp;#x27;t consume that much (a &amp;quot;drop in the ocean&amp;quot;), that&amp;#x27;s because it was designed narrower to keep the PPA reasonable! The reason I can&amp;#x27;t feed my Zen backend isn&amp;#x27;t because having a wide frontend is useless and I should just enable SMT anyways, it&amp;#x27;s because x86 makes wide decodes much less practical than competing architectures.</text></item></parent_chain><comment><author>BeeOnRope</author><text>x86-64 is not even a particularly compact encoding even compared to contemporary fixed length encodings. The inherent advantage of variable length encoding is largely cancelled out by wasted encoding space for legacy cruft.&lt;p&gt;Aarch64 is roughly on par for encoding density.</text></comment>