June 22nd, 2024

Arm64EC – Build and port apps for native performance on Arm

Arm64EC is a new ABI for Windows 11 on Arm devices, offering native performance benefits and compatibility with x64 code. Developers can enhance app performance by transitioning incrementally and rebuilding dependencies. Specific tools help identify Arm64EC binaries and guide the transition process for Win32 apps.

Read original articleLink Icon
Arm64EC – Build and port apps for native performance on Arm

Arm64EC is a new application binary interface (ABI) for apps running on Arm devices with Windows 11, allowing for native performance benefits like improved power consumption and accelerated AI & ML workloads. It enables interoperability with x64 code running under emulation in the same process, ensuring native performance for Arm64EC code. By incrementally transitioning existing x64 apps to Arm64EC, developers can enhance performance without recompiling the entire application at once. Arm64EC binaries can link both x64 and Arm64EC libs, while Arm64 binaries can only link Arm64 libs. Dependencies should be rebuilt as Arm64EC versions for optimal performance. Developers can identify Arm64EC binaries using specific tools like the developer command prompt or Windows Task Manager. The transition to Arm64EC is detailed in the article, providing guidance on updating Win32 apps using this new ABI.

Related

Show HN: Eidos – Offline alternative to Notion

Show HN: Eidos – Offline alternative to Notion

The Eidos project on GitHub offers a personal data management framework as a Progressive Web App with AI features. Customizable with extensions and scripting, it leverages sqlite-wasm technology for chromium-based browsers.

Exposition of Front End Build Systems

Exposition of Front End Build Systems

Frontend build systems are crucial in web development, involving transpilation, bundling, and minification steps. Tools like Babel and Webpack optimize code for performance and developer experience. Various bundlers like Webpack, Rollup, Parcel, esbuild, and Turbopack are compared for features and performance.

Hacking eInk Price Tags (2021)

Hacking eInk Price Tags (2021)

Hackers repurpose eInk electronic shelf labels (ESLs) into photo frames or status displays by customizing firmware. Detailed exploration of hacking challenges, including Marvell chip analysis, bootloader functions, memory storage, communication protocols, and debugging methods.

Why are module implementation and signatures separated in OCaml? (2018)

Why are module implementation and signatures separated in OCaml? (2018)

Separation of module implementation and signatures in OCaml enables scalable builds, creation of cmi files, and streamlined interface modifications. Emphasizing abstraction and implementation separation enhances modular programming and system reasoning.

Gren 0.4: New Foundations

Gren 0.4: New Foundations

Gren 0.4 updates its functional language with enhanced core packages, a new compiler, revamped FileSystem API, improved functions, and a community shift to Discord. These updates aim to boost usability and community engagement.

Link Icon 10 comments
By @jart - 4 months
Wow! This might actually make it possible for Actually Portable Executable to support running on Windows ARM. I'm already putting the ARM code inside all my binaries. There's just never been a way to encode that in the PE headers. But if my emulated WinMain() function for x86-64 could detect that it's being emulated and then simply ask a WIN32 API to jump to the ARM entrypoint instead, it'd be the perfect solution to my problems. I actually think I'm going to rush out and buy a Windows ARM computer right now.
By @Aissen - 4 months
A long-term contributor to LuaJIT (@corsix) added Arm64EC support and introduced the franken ABI at FOSDEM 2024, with a very entertaining talk: https://fosdem.org/2024/schedule/event/fosdem-2024-1762-arm6...
By @classichasclass - 4 months
This ( https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi ) feels a lot like a modern rethinking of Universal Procedure Pointers (i.e., between PowerPC and the 68K emulator on Power Macintosh).
By @userbinator - 4 months
Windows 9x can run 16-bit realmode (V86), 16-bit protected mode, and 32-bit protected mode code in the same process by using different segment descriptors. Too bad amd64 wasn't compatible with that model, nor the virtualisation features that came afterwards, or Intel could've made ARM32/64-mode segments a reality if they decided to add an ARM decoder to their microarchitecture.
By @sylware - 4 months
Funny, I started to code some of my linux x86_64 programs... using RV64 assembly (the new C), with a small in-process RV64 assembly interpreter.

Everything seems to converge more and more toward RISC-V these days.

By @Symmetry - 4 months
Sounds similar to what NVidia was doing with their Project Denver cores, using a mix of emulated ARM and native VLIW instructions with gradual compilation from one to another.
By @frozenport - 4 months
Struggling with the use case.

It seems like this is when you have the source or the libs but choose to mix x86 and arm?

It would seem if you have the source etc you should just bite the bullet and port everything.

By @Tempest1981 - 4 months
> requires the use of the Windows 11 SDK and is not available on Windows 10 on Arm.

So what should developers do re: Win10 users? Separate builds for them?

By @spullara - 4 months
How is this different than what Apple did for the x86 -> ARM transition?
By @nomercy400 - 4 months
So is this Arm64EC Windows-only? Is it standardized?

If not, is this not just another target architecture? You cannot use it on arm64 architectures, and your app already supports x86.