[a64] Implement an ARM64 backend #2259
Draft
+11,530
−73
Conversation
This file contains 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.
|
Debugger, instruction-stepping, call-stack unwinding, etc have been implemented as well: |
|
Latest iteration running Beautiful Katamari and Geometry Wars. Still some minor issues but serving gameplay now. kata.mp4geo.wars.mp4 |
|
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.
Passes cpu-ppc-tests
This is a very literal translation from the x64 code into ARM and may not be very optimized. Passes unit test save for a couple off-by-one errors.
Adds two new flags for allowing the use of LSE and FP16C
Narrow-saturation instructions causes off-by-one rounding errors. Using the min+max+shuffle passes more unit tests
Load the pointer to the VConst table once, and use offsets from this base address from the underlying enum value. Reduces the amount of instructions for each VConst memory load.
Detect when all bytes are repeating and use `MOVI` when applicable
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? |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.