Is your feature request related to a problem? Please describe.
When migrating to 64-bit NVDA, we'd still be using an AMD64 version on ARM64 systems. A fully native arm64 version of NVDA would require a separate distribution of NVDA, since it needs a separate interpreter. I assume that is out of scope.
Describe the solution you'd like
Build all NVDA helper code for ARM64EC as well, this means, we'd have 4 lib folders in the end:
- X86, containing NVDA Helper remote and vbuf backends for x86 compatibility
- ARM64, containing NVDA Helper remote and vbuf backends for compatibility with native ARM64 processes
- X64, containing all the libraries, helper local, remote, liblouis, etc.
- ARM64ec: also contains all the libraries like x64, but loaded on ARM64 systems, since the AMD64 python bundled with NVDA should be able to load ARM64EC code within the AMD64 process.
Basically, the native arch for all dll's loaded into NVDA should be X64 on AMD64 and ARM64ec on arm64.
Describe alternatives you've considered
Just run native AMD64 code on ARM64, but that's probably slower then the ARM64EC code, which is optimized for ARM.
Additional context
Related to #18207
ARM64EC is a special ABI from Microsoft that allows binaries to run natively on ARM64 hardware while remaining binary-compatible with x64. This means ARM64EC code can directly interoperate with x64 processes. On Windows ARM systems, running x64 code normally requires full emulation, which is slower. By using ARM64EC, we can compile performance-critical parts of NVDA to run natively on ARM64 while still relying on existing x64 code (e.g. Python interpreter) for the rest.
According to Microsoft, ARM64EC has native performance on ARM64 systems, compared to limited performance for emulated X64 code.
What this means for NVDA on ARM64:
- No longer use x64 NVDAHelper, but compile NVDAHelper for ARM64EC instead
- Also include
nvdaHelperLocal.dll, nvdaHelperLocalWin10.dll and UIARemote.dll.
- There will still be three architectures we need to support on ARM64. x86 is covered by the x86 libraries, arm64 is covered by the arm64 libraries, x64 is covered by the arm64ec libraries.
Is your feature request related to a problem? Please describe.
When migrating to 64-bit NVDA, we'd still be using an AMD64 version on ARM64 systems. A fully native arm64 version of NVDA would require a separate distribution of NVDA, since it needs a separate interpreter. I assume that is out of scope.
Describe the solution you'd like
Build all NVDA helper code for ARM64EC as well, this means, we'd have 4 lib folders in the end:
Basically, the native arch for all dll's loaded into NVDA should be X64 on AMD64 and ARM64ec on arm64.
Describe alternatives you've considered
Just run native AMD64 code on ARM64, but that's probably slower then the ARM64EC code, which is optimized for ARM.
Additional context
Related to #18207
ARM64EC is a special ABI from Microsoft that allows binaries to run natively on ARM64 hardware while remaining binary-compatible with x64. This means ARM64EC code can directly interoperate with x64 processes. On Windows ARM systems, running x64 code normally requires full emulation, which is slower. By using ARM64EC, we can compile performance-critical parts of NVDA to run natively on ARM64 while still relying on existing x64 code (e.g. Python interpreter) for the rest.
According to Microsoft, ARM64EC has native performance on ARM64 systems, compared to limited performance for emulated X64 code.
What this means for NVDA on ARM64:
nvdaHelperLocal.dll,nvdaHelperLocalWin10.dllandUIARemote.dll.