Conversation
0fdaa3a to
217986d
Compare
Closed
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
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.
Instead of loading and storing only the registers a basic block uses, load all the registers when entering JIT code, and store them all when exiting JIT code.
There's two benefits with this approach:
With block linking this should result in fewer total loads/stores that should boost performance a tiny bit and reduce code size per block, and maybe even more when call/ret and indirect linking is established fully
Asynchronous signals can happen at any point in JIT code. Our previous solution was to walk the block instructions to find all the modified registers, and pull them from ucontext. This is a hacky solution and it also shuts down future opportunities for multiple block compilation -- we can't walk recompiled code that contains control flow instructions. With this rewrite we are guaranteed the fact that while we are in JIT code the statically allocated GPRs will contain the correct values. We also have a flag
state_is_correctin ThreadState, when we writeback the registers we set it to 0 so that we can modify the registers willy nilly as the ThreadState has the correct values and we don't need to pull from ucontext. This happens for example when we want to call a function (like felix86_syscall) and we writeback the state and overwritea0which is otherwise an allocated registerThere's also a downside:
Problems to resolve before merging:
Balatro is flakyAlways has been?apt install supertux2(package doesnt exist, irrelevant)felix86 0.1.0.217986d
VLEN: 256
cpu: Spacemit X60 (8) @ 1.600GHz
gpu: AMD ATI Radeon HD 7350/8350 / R5 220
model: Milk-V Jupiter
distro: Bianbu 2.1.1 riscv64
de: GNOME 46.0
wm: Mutter
kernel: 6.6.63
memory: 979MiB / 7836MiB