LekKit
JIT: Considering dropping 32-bit backends
Why?
TLDR: You don't benefit from 32-bit JIT anyways, unless you're running an obscure riscv32 guest, for same reason they are not tested too well. This will not cause any functional breakage.
- There is no way to accelerate a 64-bit guest with a native 32-bit JIT as of now, as the middleware does not provide a way to lower 64-bit operations into 32-bit instructions
- RVJIT needs a big rework, including reimplementation of public backend interfaces and new native intrinsics
- Both arm32 and i386 are very lacking in advanced instructions and hold back the whole thing
- No one maintains the arm32 backend, i386 backend is held on tape and sticks as part of x86_64 backend
- Oh we have a riscv32 backend? I only remembered about it midway typing this, anyways the hardware where it could run is pretty much non-existent
- RVJIT Linker is not implemented for arm32, requiring fallback handling
- Focusing on 64-bit backends will allow to drop fallbacks for 32-bit hosts, use more advanced instructions like SSE2, ARM64 VFP/NEON, etc as a baseline
- This is not a feature breakage in any way, any non-JITed host target will continue to run guests via generic interpreter
Why not?
- Someone may want to accelerate riscv32 guests on dated host hardware (???)
- Respecting the author of the arm32 backend (Although I think the arm64 already serves this purpose and will serve us for the observable future)
- Maybe the RVVM v0.7 release will keep those backends alive a bit more for those reasons
Alternative
It might be a much better idea to implement a generic "glue" JIT backend which will copy-paste precompiled functions into native code sequences and have zero architecture-specific code in it. This would allow at least some amount of 64-bit guest acceleration, and support for various host architectures beyond arm32 and i386 with minimal efforts
Seems that arm32 JIT backend miscompiles instructions in some cases
How to reproduce: Purposely break FPU tests by defining FPU_LIB_CONFORMING_SIGNALING_COMPARE for arm32 in src/fpu_lib.h, run tests, somehow the failure of fcmp tests will cause a JIT miscompilation and SIGILL.
Someone may want to accelerate riscv32 guests on dated host hardware (???)
There are some Android devices still shipping with 32-bit kernel/userspace. From the Android 16 CCD:
If Handheld device implementations include greater than or equal to 2GB and less than 4GB of memory available to the kernel and userspace, they: [7.6.1/H-SR-1] Are STRONGLY RECOMMENDED to support only 32-bit userspace (both apps and system code) If Handheld device implementations include less than 2GB of memory available to the kernel and userspace, they: [7.6.1/H-1-1] MUST only support a single ABI (either 64-bit only or 32-bit only).
The glue backend would probably work good enough for these devices, unless anyone wants to fix and extend the 32-bit backends to support riscv64. Distro support for riscv32 is virtually nonexistent outside of source-based distros (Gentoo, Buildroot, Yocto, etc).
