run on and build for Windows on ARM64

[rainers]

This allows to build and run the runtime with ldc-build-runtime and option -march=arm64 on Windows on ARM. The compiler used is the one for x64 (it shows some floating-point inaccuracies in the x86-emulator).

All druntime unittests pass but the two disabled ones involving chained exceptions in fibers.

In phobos a std.process test fails (but also for emulated x64) and a tests in std.outbuffer indicates that there is still an issue with va_arg handling. Without a curl build, the respective tests fail, too.

I haven't yet managed to run the compiler test suite on the ARM machine.

[kinke]

All druntime unittests pass but the two disabled ones involving chained exceptions in fibers.

In phobos a std.process test fails (but also for emulated x64) and a tests in std.outbuffer indicates that there is still an issue with va_arg handling. Without a curl build, the respective tests fail, too.

Awesome! I'd have expected much more needed tweaks to get so far already.

Wrt. va_arg - core.stdc.stdarg has a version(Win64) block before version(AAPCS64):

ldc/runtime/druntime/src/core/stdc/stdarg.d

Line 181 in 45670c2

T va_arg(T)(ref va_list ap)

[rainers]

Awesome! I'd have expected much more needed tweaks to get so far already.

I was surprised aswell :)

Wrt. va_arg - core.stdc.stdarg has a version(Win64) block before version(AAPCS64):

Turns out it was about va_list, that seems to be a pointer only, as on Darwin. Seems fixed now.

[rainers]

Finally figured out what was wrong with the fiber code. All unittests pass now for druntime and phobos (curl not tested, one std.process test fails both for arm64 and x64).

[kinke]

Oh and please add a changelog.md entry. Rest LGTM, thanks!

[kinke]

[dmd.vsoptions will need some extensions for AArch64 support too, it currently just features a bool x64 argument to differentiate between x86 and x64. Edit: No requirement for this PR.]

[kinke]

As a follow-up, we could build and bundle the ARM64 libraries with the windows-multilib installation package, incl. an ldc2.conf tweak. So that cross-compiling via -mtriple=arm64-windows-msvc works out of the box (edit: with an installed ARM64 MSVC toolchain).

[rainers]

As a follow-up, we could build and bundle the ARM64 libraries with the windows-multilib installation package, incl. an ldc2.conf tweak. So that cross-compiling via -mtriple=arm64-windows-msvc works out of the box (edit: with an installed ARM64 MSVC toolchain).

I added the entry in ldc2.conf yesterday: when compiling with -march=arm64 the triple came out as aarch64-pc-windows-msvc. With the ARM64 environment set up with vcvarsamd64.cmd it then linked without issues.

Is there a way to cross-compile and run the tests in a CI on WoA?

[kinke]

I guess if Microsoft takes it seriously with ARM this time, then we're gonna see Windows ARM64 runners for GitHub Actions too. Then we can build a native package, incl. all tests.

All the other CI systems (we have in use and I know about) have monthly limits by now (thx cryptokiddies), so I don't encourage checking whether they'd have WinARM support already.

[kinke]

Btw, out of interest - how slow is the x64 emulator on the ARM box? Comparable to Apple's Rosetta 2?

[rainers]

Btw, out of interest - how slow is the x64 emulator on the ARM box? Comparable to Apple's Rosetta 2?

No real measurements so far, but the emulator performance seems pretty good. When compiling for ARM64EC, you can also mix Intel and ARM binaries in a single process, or even within one binary. Marshaling between native and emulated code causes some notable slowdowns, though.

[rainers]

I just tested Visual D on ARM (VS doesn't support x86_64 extensions as it is not compiled as ARM64EC), but unfortunately it crashes when loading a D source file. Not analyzed yet in detail, but I suspect an issue with std.concurrency used in communication with dmdserver.xe .

[kinke]

When compiling for ARM64EC, you can also mix Intel and ARM binaries in a single process, or even within one binary. Marshaling between native and emulated code causes some notable slowdowns, though.

Yeah. there's #4771. I'm a bit skeptical in that regard; seems like an escape hatch to extend some legacy x86 code base with new native ARM plugins, which might provide better performance than the emulated x86 plugin.

I hope it's not Micrsoft code bases that they intend to keep x86-only for a while, similar to how it took them decades (?) to make the Visual Studio IDE a 64-bit x86_64 program... ;)

[kinke]

VS doesn't support x86_64 extensions as it is not compiled as ARM64EC

Oh wow. This is exactly what I thought this ARM64EC would be for, keeping up support for all the existing x86 plugins. lol

Edit: Oh well, if they did, then it wouldn't support any normal native ARM plugins, but require all of them to be compiled as ARM64EC. And then they'd probably have to go with that format for decades. - Even more skeptical now.

[rainers]

but unfortunately it crashes when loading a D source file.

Turned out stack scanning was missing the proper top of stack. Fixed now and Visual D runs (only very little testing done). The debugger extension doesn't yet work, though, but that's a C++ DLL.

[rainers]

Oh wow. This is exactly what I thought this ARM64EC would be for, keeping up support for all the existing x86 plugins. lol

Yeah, I was pretty surprised, too. Not sure if there are any downsides to ARM64EC but a slightly different ABI. I doubt there are any performance issues if you just build for ARM64 anyway, but it might keep people from porting to ARM to begin with.

[kinke]

2 incompatible ABIs for a 'new' platform - IMO a recipe for disaster. Especially if the x86 emulation performance isn't too bad, and AFAICT, all ARM64EC would enable is better performance by having some parts of a process in native code. E.g., they could still provide an x86 VS build as install option on ARM, to keep the x86 plugins working. If Microsoft themselves aren't using ARM64EC for stuff like VS (and Office - no idea if they do), then it's dead on arrival to me.

Apple has shown that transitioning from Intel to ARM can be quite smooth with a built-in emulator, no need for an extra ABI to be able to mix architectures in a single process.

---

Feel free to merge when ready. [You could bump the Phobos submodule here and add the PR refs to the changelog entry.]