Arm64EC is a Microsoft application binary interface that allows Windows on Arm to run native Arm applications alongside emulated x64 applications in the same process.

How does Arm64EC compare to Apple's Rosetta?

Unlike Arm64EC, which allows for the mixing of Arm and x64 code within the same process, Apple's Rosetta requires all code in a process to be either Arm or x86, not both.

What performance trade-offs are associated with Arm64EC?

Arm64EC incurs performance trade-offs due to fewer CPU registers available and overhead from indirect calls, which require additional checks.

Will applications using Arm64EC improve over time?

Yes, as Microsoft continues to update Windows on Arm, enhancements to Arm64EC may result in better compatibility and performance.

Is Arm64EC supported by other platforms?

While Arm64EC is a Microsoft-specific design, it has also been implemented in Wine, showing potential for cross-platform use.

Windows on Arm: Running Native Arm and Emulated x64 Code Together

Microsoft's Windows on Arm introduces Arm64EC, enabling running native Arm and emulated x64 code in the same application, unlike Apple's Rosetta. This marks a pivotal evolution in cross-architecture compatibility.

Introduction

Microsoft has introduced a significant advancement in the way Windows on Arm can run applications. Unlike Apple, which restricts applications to either run natively or emulated but not both, Windows on Arm offers the ability to run native Arm code alongside emulated x64 code within the same process. This capability is made possible through a unique technology called Arm64EC.

Understanding Arm64EC

Arm64EC, short for Arm64 Emulation Compatible, is a specific application binary interface (ABI) designed by Microsoft. Released alongside Windows 11 on Arm in 2021, it enables a seamless integration between native Arm applications and existing x64 applications and plugins, which significantly improves compatibility and user experience.

This hybrid approach allows developers to compile their applications so that they can run native Arm code while simultaneously being able to load x64 plugins. For instance, it facilitates running x64 add-ins in applications like Microsoft Office that were previously incompatible with Arm. This integration enhances the usability of existing software libraries and tools in the Arm environment, thereby encouraging developers to adapt applications for Arm architecture.

Technical Specifications of Arm64EC

Feature	Description
ABI Compatibility	Arm64EC allows for running Arm code while adhering to x64-compatible software conventions.
CPU Register Allocation	Arm64EC utilizes fewer CPU registers and some indirect calls have to undergo additional checks.
Direct and Indirect Calls	Direct calls between Arm64EC functions operate as normal Arm calls, whereas jumps to x64 require additional translation.
Memory Layout Compatibility	Data structures are arranged to follow x64 conventions while using Arm's native instruction set.
Emulation Support	Compatible with Windows' emulation for x64 and is utilized in Wine's implementation for x64 code execution.

Performance Trade-Offs

Despite its innovative approach, Arm64EC comes with trade-offs. The architecture does yield fewer available CPU registers compared to pure Arm64, which can affect performance. For example, while Arm has 31 general-purpose registers, x64 is limited to 16. Every indirect call, which is critical in interoperability, incurs overhead because of the checks required to determine whether the call is to Arm or x64 code.

This overhead must be considered by developers, especially when optimizing applications for performance. Additionally, the mapping of Arm registers to comply with x64's calling conventions leads to the restriction of certain registers, including some vector registers, which further complicates the performance profile.

Comparison with Apple's Silicon Transition

Apple's transition to its own silicon architecture deviates significantly from Microsoft's approach. Apple's Rosetta 2, the emulation framework, complicates integration by prohibiting mixing of Arm and x86 code within a single process. As a result, applications that require Intel plugins must run those components in separate processes and communicate over inter-process communication (IPC).

In contrast, Microsoft’s Arm64EC allows developers to write applications that can load x64 plugins seamlessly without needing to recompile for Arm exclusively, maintaining backward compatibility with existing software ecosystems.

The Role of Thunks and Call Checkers

To bridge the differences between the Arm and x64 architectures efficiently, Microsoft has implemented a system of thunks and call checkers. A “thunk” is a small piece of code that allows for the translation of function calls. For instance, when an x64 application calls an Arm64EC function, the entry thunk rearranges the arguments from x64's storage format into Arm's suitable format. Similarly, the exit thunk performs the reverse operation when Arm64EC functions need to call x64 code.

This method handles the complexity involved in the calling conventions of both architectures, ensuring smooth transitions without sacrificing application integrity or performance.

Microsoft’s 64-bit Office on Arm

One of the principal applications benefiting from Arm64EC is Microsoft Office. The 64-bit version of Office for Arm was specifically designed to handle existing x64 plugins seamlessly, allowing users to continue using critical add-ins without requiring a complete transition to Arm-native versions. The architecture reflects Microsoft's commitment to maintaining historical software relationships while promoting the adoption of Arm architecture.

Future Prospects for Arm and x64 Compatibility

As Windows continues to evolve, the implications of Arm64EC might pave the way for richer compatibility frameworks between disparate architectures. Furthermore, Microsoft’s continued support for this technology, combined with community contributions (like the independent implementation by Wine), suggests that there may be broader adoption of Arm compatibility strategies across different platforms.

Future updates to Windows on Arm may also enhance Arm64EC's capabilities, as developers push for more optimized performance and feature sets that leverage both Arm and x64 strengths.

Key Takeaways

Arm64EC enables simultaneous execution of Arm and emulated x64 code.
Microsoft's design promotes plugin compatibility without the need for complete rewrites.
Arm64EC involves performance trade-offs due to fewer available CPU registers.
The technology highlights significant differences compared to Apple's approach to silicon transition.
Future developments may expand and enhance the compatibility between Arm and x64 ecosystems.

Conclusion

The introduction of Arm64EC in Windows on Arm signifies a substantial step forward, addressing compatibility issues that have historically restricted the use of x64 applications in the Arm ecosystem. While Microsoft navigates the complexities inherent in supporting two different architectures, the technical solutions deployed showcase an engaging shift towards greater cross-compatibility in software design. With ongoing updates and community support, the future of Windows on Arm remains promising.