Hacker News Reader

Comment by 0x0 | Hacker News Reader

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?

View on HN

Compatibility 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.

I 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!

https://www.linkedin.com/pulse/emulators-paradox-new-archite...

ARM64EC will be a documented ABI for 3rd-party compiler developers.

It hardly matters, it isn't as if one OS executable is blindly being put to execution in another platform.

Native code isn't bytecodes.

DLLs shipped with the OS (and quite some 3rd-party ones too) are ARM64X. This means that they expose both the ARM64 and ARM64EC ABIs.

ARM 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.

Are you sure? https://docs.microsoft.com/en-us/windows/win32/winprog64/wow... suggests otherwise.

I'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.

Not 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.

I 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).

Reply on news.ycombinator.com