7 ms·
Arm64EC – Build and port apps for native performance on Arm
- classichasclass 2y agoThis ( https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi 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).
- jart 2y agoWow! 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.
- yjftsjthsd-h 2y agoAnd this kind of beautiful insanity is why you're one of my favorite developers of this era. Also, > I'm already putting the ARM code inside all my binaries. Wait, I thought CPU architecture was the one limitation that did affect APE - you mean on unix-likes APE binaries are already compatible across amd64 and aarch64? Edit: rereading https://justine.lol/cosmo3/ https://justine.lol/cosmo3/ it does say that, doesn't it - and ARM64 listing "Windows (non-native)" just means that one platform uses (for the next few hours-days, at least...) emulation. That's amazing:)
- zorgmonkey 2y agoI'm pretty sure the API you'll want to detect that is IsWow64Process2.
- szundi 2y agoI love the 2s and Exes at the end of Windows API call names
- formerly_proven 2y agowait/waitid/waitpid/wait3/wait4 dup/dup2/dup3 creat/open/openat/openat2 cough
- skissane 2y agoEven more: clone3, __clone2 (only exists on Itanium), fchmodat2, preadv2, pwritev2, pipe2, sync_file_range2, mmap2 (only certain architectures; for x86, only 32-bit), renameat2, mlock2, faccessat2, epoll_pwait2 My personal prediction is sooner or later we'll see execveat2, to permit setting /proc/PID/comm when using execveat [0]. I doubt we'll ever see clone4, because clone3 is passed a structure argument with the structure size, so new fields can be supported just by increasing the structure size. If other syscalls had done that from the start, much of the 2/3/etc would have been avoided. It is actually a very common practice on Windows (since NT), it has only much more recently been adopted in the Linux kernel [0] see https://uapi-group.org/kernel-features/ https://uapi-group.org/kernel-features/
- phaedrus 2y agoI work on a team that supports some equipment related to airplanes. An acronym for one piece of equipment that is decades old is "RCSU". When I got a support call talking about "RSCU", I assumed the person meant "RCSU". Nope. It turns out, when they made their next-generation piece of equipment, the vendor differentiated it by swapping the inner two letters in an already easy-to-say-wrong acronym. My reaction was, "WTF didn't they just call it the RCSU2?!"
- Just_Harry 2y agoMy favourite is MapViewOfFile3FromApp [0], which is one of the seven variants of MapViewOfFile. [0]: https://learn.microsoft.com/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile3fromapp https://learn.microsoft.com/windows/win32/api/memoryapi/nf-m...
- lewurm 2y ago> I actually think I'm going to rush out and buy a Windows ARM computer right now. If you have an Apple Silicon machine you can run a Windows Insider build via UTM in a VM.
- mappu 2y agoI found the http://www.emulators.com/docs/abc_arm64ec_explained.htm http://www.emulators.com/docs/abc_arm64ec_explained.htm article extremely helpful at understanding what the ABI is doing, you might like it too.
- szundi 2y agoQuickly create a donation page, you have this moment haha
- dwattttt 2y agoPE headers have a field for machine type, you're looking for Machine in FileHeader: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#coff-file-header-object-and-image https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... and https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... EDIT: Or maybe what you're looking for is hybrid PEs? https://ffri.github.io/ProjectChameleon/new_reloc_chpev2/ https://ffri.github.io/ProjectChameleon/new_reloc_chpev2/
- justinfrankel 2y agoIf you have an Apple Silicon mac you can install Win11 in UTM and it works great for dev purposes. Can get the free builds via Windows Insider, too.
- conradev 2y agoI would recommend getting an official consumer build to test all of the latest consumer features like Copilot Parallels has a Microsoft partnership and has an official AMR64 image which I was able to grab (and run in anything). I’m sure there are a lot more now, though!
- dboreham 2y ago> could detect that it's being emulated Down the rabbit hole... > buy a Windows ARM computer You can still get Surface Pro X (16G/LTE) on Amazon for $800
- officeplant 2y agoIf you're lucky you can also find the snapdragon thinkpads for under $350 on amazon.
- adastra22 2y agoWhoa
- officeplant 2y agounfortunately that time seems to have passed, the refurb units I can find now are back up to $650.
- darby_nine 2y agoIt looks like this might be provided by "Arm64X", which does seem to encode the dual-arch nature at the binary level: https://learn.microsoft.com/en-us/windows/arm/arm64x-pe https://learn.microsoft.com/en-us/windows/arm/arm64x-pe
- userbinator 2y agoWindows 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.
- st_goliath 2y ago> ... 16-bit realmode (V86), 16-bit protected mode, and 32-bit protected mode code in the same process by using different segment descriptors... > ...Intel could've made ARM32/64-mode segments a reality... While I myself admire this particular breed of masochism, the direction that Intel currently wants to take is apparently quite the opposite. In May last year, they proposed X86S[1][2][3] which tosses out 16-bit support completely, along with 32 bit kernel mode (i.e. the CPU boots directly into 64 bit mode, 32 bit code is only supported in ring 3). The proposal trims a lot of historical baggage, including fancy segmentation/TSS shenanigans, privilege rings 1 & 2, I/O port access from ring 3, non-flat memory models, etc... limiting the CPU to 64 bit kernel mode, and 64 or 32 bit x86 user mode. With the requirement for 64 bit kernel mode, it effectively also removes un-paged memory access. [1] https://en.wikipedia.org/wiki/X86-64#X86S https://en.wikipedia.org/wiki/X86-64#X86S [2] https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html https://www.intel.com/content/www/us/en/developer/articles/t... [3] https://news.ycombinator.com/item?id=36006446 https://news.ycombinator.com/item?id=36006446
- cesarb 2y ago> the direction that Intel currently wants to take is apparently quite the opposite. It's not just Intel. It's clear that ARM is also going in the same direction, by allowing newer cores to be 64-bit (AArch64) only, dropping compatibility with the older 32-bit ARM ISA (actually three ISAs: traditional 32-bit ARM, Thumb, and Thumb2), and IIRC some manufacturers of ARM-based chips are already doing that.
- 2y ago
- frozenport 2y agoStruggling 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.
- adamjs 2y agoTwo use-cases jump to mind: * Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.) * Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)
- callalex 2y agoAt that point why trust the emulator over the port? Either you have sufficient tests for your workload or you don’t, anything else is voodoo/tarot/tea leaves/SWAG.
- frozenport 2y agoYeah but you need to port the SIMD before shipping anyways? So if you're doing incremental stuff might as well stub out the calls with "not implemented", and start filling them in.
- creshal 2y ago
- nomercy400 2y agoSo 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.
- ComputerGuru 2y agoIt’s not anything special, it’s arm code compiled with the x64 abi. The theory behind it is simple enough.
- Aissen 2y agoA 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-arm64ec-microsoft-s-emulation-frankenstein/ https://fosdem.org/2024/schedule/event/fosdem-2024-1762-arm6...
- Tempest1981 2y ago> 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?
- AshamedCaptain 2y agoThe same thing you do for users of all previous failed windows on arm attempts? If you meant x86 win10 users you can use the win11 sdk to target them
- pjmlp 2y agoFrom Microsoft's point of view, ignore them after 2025, unless they pay big. In reality, yes, different builds, like it already happened with previous Windows versions.
- goosedragons 2y agoIs it really even a big enough concern to think about them? Windows 10 on ARM lacks x64 emulation support and the devices never sold well. I can't imagine there's too too many Windows 10 on ARM devices hanging around still running Windows 10.
- dmitrygr 2y ago> Windows 10 on ARM lacks x64 emulation support The last build of win10 on arm supported x64 and many of us who do not want win11 still use it.
- goosedragons 2y agoSort of. An insider build that was never fully released. Does that even get updates anymore?
- dmitrygr 2y agoWindows Update? Why would you volunteer for that experience‽‽‽ It is a VM in my MacBook. It needs no updates
- sylware 2y agoFunny, 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.
- Symmetry 2y agoSounds 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.
- spullara 2y agoHow is this different than what Apple did for the x86 -> ARM transition?
- anaisbetts 2y agoARM64EC is usually for stuff like plugins or really large apps - most people will simply compile an ARM64 and x64 version of their app
- duskwuff 2y agoRosetta 2 operates on the process level -- on an Apple Silicon system, a process can run an ARM executable and run all ARM code, or can run an x86_64 executable and run all x86_64 code. ARM64EC allows processes to run a mixture of native and emulated code. Whether this is actually useful is debatable, but the option exists.
- tedunangst 2y agoRosetta allows loading x86 plugins into arm apps.
- duskwuff 2y agoSource? My understanding is that cross-architecture plugins are handled out of process over XPC.
- tedunangst 2y agoThat sounds right. I think I misread a source. Was just looking at this yesterday, but didn't look close enough.
- tedunangst 2y agoIt requires you to recompile your application a third time if you want to load x64 plugins, and then it becomes incompatible with arm plugins.