{"id":37749,"date":"2022-11-29T16:11:50","date_gmt":"2022-11-29T21:11:50","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=37749"},"modified":"2022-12-14T15:02:02","modified_gmt":"2022-12-14T20:02:02","slug":"why-rosetta-2-is-fast","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/11\/29\/why-rosetta-2-is-fast\/","title":{"rendered":"Why Rosetta 2 Is Fast"},"content":{"rendered":"

Dougall Johnson<\/a> (Hacker News<\/a>):<\/p>\n

\n

Generally translating each instruction only once has significant instruction-cache benefits – other emulators typically cannot reuse code when branching to a new target.<\/p>\n

[…]<\/p>\n

Given these constraints, the goal is generally to get as close to one-ARM-instruction-per-x86-instruction as possible, and the tricks described in the following sections allow Rosetta to achieve this surprisingly often. This keeps the expansion-factor as low as possible. For example, the instruction size expansion factor for an sqlite3 binary is ~1.64x (1.05MB of x86 instructions vs 1.72MB of ARM instructions).<\/p>\n

[…]<\/p>\n

All performant processors have a return-address-stack to allow branch prediction to correctly predict return instructions.<\/p>\n

Rosetta 2 takes advantage of this by rewriting x86 CALL<\/strong> and RET<\/strong> instructions to ARM BL<\/strong> and RET<\/strong> instructions (as well as the architectural loads\/stores and stack-pointer adjustments). This also requires some extra book-keeping, saving the expected x86 return-address and the corresponding translated jump target on a special stack when calling, and validating them when returning, but it allows for correct return prediction.<\/p>\n

[…]<\/p>\n

The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS<\/strong>, SUBS<\/strong> and CMP<\/strong> compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n