[a64] Implement an ARM64 backend #2259
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Separates the `Windows` platform into `Windows-x86_64` and `Windows-ARM64`. Adds `--arch` argument to `build`. Removes x64 backend on non-x64 targets.
Marked as TODO for now
Adding the `a64` backend will be a different PR. For now it's stubbed to the null backend to allow the main executable to open without failing initalization.
This value is currently returning `0` on ARM machines and throws an exception.
Contributor Author
| Debugger, instruction-stepping, call-stack unwinding, etc have been implemented as well: |
Contributor Author
| Latest iteration running Beautiful Katamari and Geometry Wars. Still some minor issues but serving gameplay now. kata.mp4geo.wars.mp4 |
Contributor Author
| No longer requires Armv8.1. Instructions are emitted with an Armv8.0-a baseline and will detect features such as FP16 and LSE and such before utilizing them(and expose them in the feature-mask config similar to x64). |
Wunkolo force-pushed the arm64-backend branch 3 times, most recently from 4fa2462 to 54790a4 Compare Open
Addresses a build issue that seems to occur now that xenia-app is not getting SDL2 through one of its submodues
Adds the new `xenia-cpu-backend-a64` build-target with linkage following the x64 backend.
Header-only library for emitting arm64v8 instructions. Enables C++20 only for the a64 backend for now
Mostly element-accessors
First pass framework that gets emitted ARM code executing. Based on the x64 backend, implements an ARM64 JIT backend.
This just reverses the bytes of 32-bit values, not reverse the whole vector.
Indices and non-const tables were using the same scratch-register
Uses `CNTFRQ` and `CNTVCT` system-registers as a raw clock source. On my ThinkPad x13s, the raw clock source returns a tick-frequency of 19,200,000 while the platform clock source(QueryPerformanceFrequency) returns 10,000,000. Almost double the accuracy over the platform-clock!
Misses some during the first pass. Now the config files with mention a64 differences.
Read direction from the ZR in the case that we are just storing a 64 or 32 bit zero
This directly maps to the QC bit in the FPSR. Just have to make sure that the saturated instruction is the very last instruction(which is currently the case for stuff like VECTOR_ADD and such).
The 64-bit cases uses a particular Replicated 8-bit immediate so something else will have to handle that This cases a lot of cases without having to touch memory. Does not catch cases of `1.0`(0x3f800000).
`FMOV` encodes an 8-bit floating point immediate that can be used to accelerate the loading of certain constant floating point values between -31.0 and 32.0. A lot of immediates such as -1.0, 1.0, 0.5, etc fall within this range and this code gets lots of hits in my testing. This is much more optimal than trying to load a 32/64-bit value in W0/X0 and moving it into an FP register.
Uses LSE when available, but provides an armv8.0 baseline implementation.
Removes all comments relating to x64 implementation details
`dc civac` causes an illegal-instruciton on Windows-ARM. This is likely as a security measure against cache-attacks. On Linux this instruction is trapped into an EL1 kernel function. Windows does not seem to have any user-mode cache-maintenance instructions available for data-cache(only instruction-cache via `FlushInstructionCache`). The closest thing we can do for now is a full data memory-barrier with `dsb ish`. Prefetches are implemented using `prfm pldl1keep, ...`.
Out-of-bound shift-values are handled as modulo-element-size
The emitter doesn't actually hold onto executable code, but just generates the assembly-data into a buffer for the currently-resolving function before placing it into a code-cache. When code gets pushed into the code-cache, it can just be copied from an `std::vector` and reset. The code-cache itself maintains the actual executable memory and stack-unwinding code and such. This also fixes a bunch of errornous relative-addressing glitches where relative addresses were calculated based on the address of the unused CodeBlock rather than being position-independent. `MOVP2R` in particular was generating different instructions depending on its distance from the code block when it should always just use `MOV` and not do any relative-address calculations since we can't predict where the actual instruction's offset will be(we cannot predict what the program counter will be). Oaknut probably needs a "position independent" policy or mode or something so that it avoids PC-relative instructions.
These `MOV`->`DUP` splats can just be a singular `MOVI` instruction
Byte-sized constants can utilize the `MOVI` instructions. This makes many cases such as zero-splats much faster since this encodes as just a register-rename(similar to `xor` on x64).
Moves the `FMOV` constant functions into `a64_util` so it is available to other translation units. Optimize constant-splats with conditional use of `MOVI` and `FMOV`.
The last `FADDP` writes into an `S` register, which automatically masks all the other lanes to zero.
The `SUB` instruction can only encode immediates in the form of `0xFFF` or `0xFFF000`. In the case that the stack size is greater than `0xFFF`, then just align the stack-size by `0x1000` to keep the bottom 12 bits clear.
| Any progress on this possible? |
Contributor Author
| At this point this is pretty much ready for review and merging, but it depends on #2258 and xenia-project/FFmpeg#8 being merged and the submodules being updated in this repo and maybe some additional testing with more games. Though, this repo is somewhat inactive these days it seems. The last PR was merged several months ago. |
You should put this on PR on xenia-canary, its very much active. |
| @Wunkolo any plans of starting a PR on https://github.com/xenia-canary/xenia-canary ? |
Contributor Author
This is gonna sound really weird and sudden but for reasons I cannot really elaborate on right now, someone else will likely have to make the PR on canary. I kinda wish I did that from the start now 😓. |
| @Wunkolo Hi! I'm trying to merge your ARM64 PRs to Xenia-canary and it looks not bad at the moment: the build fails, but main issues are in and The build fails because compiler throws away x64 code when we compile for ARM64, while other code depends on it. |
rtissera added a commit to rtissera/xenia-canary that referenced this pull request Jun 20, 2025
| Hi team, Thanks for all the great work on ARM64 support! I’ve been following both this PR and #2259 closely as I’m interested in getting Xenia running on a Snapdragon-based Windows ARM64 device. I haven’t tested the build yet, but I’m tracking progress and would love to try it out once it’s closer to integration or available in Canary. Is there any recent update or plan to port these changes to the Canary branch? Appreciate all the effort happy to help however I can. Regards, |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Implements a 64-bit ARM backend that emits a64 instructions using oaknut.
Depends on #2258 and xenia-project/FFmpeg#8
Addresses #2002
Tested on a ThinkPad X13s and uses unit tests from #1348 as well. There is currently a ARMv8.1-a requirement due to the use of some of the newer atomic instructions such as CASAL.