4 ms·
So is there any reason at all to use the original ARM64 ABI? Adding another ABI seems like a huge undertaking. Isn't the original ARM64 windows ABI a fairly rec
by 0x0 5y ago
So is there any reason at all to use the original ARM64 ABI? Adding another ABI seems like a huge undertaking. Isn't the original ARM64 windows ABI a fairly recent invention, too? Too bad they didn't make it "ARM64EC" from the get-go?
Will there be two versions of every system dll, one for each ABI?
- kevingadd 5y agoARM support for Windows seems like it would predate this emulation effort by quite a while, but I'm not sure. Historically system DLLs on windows aren't vulnerable to this kind of API skew because there's a special ABI specifically for windows APIs referred to as "stdcall", everything exported from user32.dll etc is exposed via that ABI. I would expect the same to be true here. Note also that historically there aren't separate copies of all the system DLLs on windows for 32 and 64 bit, most of the 32 bit DLLs are full of thunks that jump to the 64-bit ones if you're running on a 64-bit Windows. So that approach would also be possible here.
- lukeh 5y agoAre you sure? https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details https://docs.microsoft.com/en-us/windows/win32/winprog64/wow... suggests otherwise.
- kevingadd 5y agoI'm not sure what you mean, it says right there in the article that the 32->64 stuff is done in user mode and that there are thunks in the 32-bit binaries.
- hrydgard 5y agoNot the case. Actual thunking is only done when calling into the kernel, you can't load a 32-bit DLL into a 64-bit process or vice versa.
- fredoralive 5y agoI think GP is thinking more of how Windows 9x did 16 and 32 bit, which was full of funky thunking and only really had one set of libraries AFAIK (awaiting inevitable correction).
- TickleSteve 5y agoCompatibility with the rest of the ARM development & tooling world is one fairly large reason to stick with the original ARM64 ABI. I would imagine, for example that GCC would not now work for ARM64EC and therefore you're getting locked-in to a Microsoft world by using this.
- arthur2e5 5y agoI can actually imagine a SysV x64 flavor of ARM64EC becoming a thing in the future, assuming of course there’s no patent barrier. GCC would not work for now without the devs having even seen it, but there is no reason they would not add it. It does support stdcall on x86 after all!
- my123 5y agohttps://www.linkedin.com/pulse/emulators-paradox-new-architectures-dilemma-pedro-justo https://www.linkedin.com/pulse/emulators-paradox-new-archite... ARM64EC will be a documented ABI for 3rd-party compiler developers.
- pjmlp 5y agoIt hardly matters, it isn't as if one OS executable is blindly being put to execution in another platform. Native code isn't bytecodes.
- my123 5y agoDLLs shipped with the OS (and quite some 3rd-party ones too) are ARM64X. This means that they expose both the ARM64 and ARM64EC ABIs.