I can’t find the source code for this, I am posting here to save it to remind myself to search later.
I think there will be cases that do not work. For example, default memory access semantics of multi-threaded code are different for x86 compared to ARM - the code likely contains assumptions that are not valid on ARM.
Elevator achieves performance on par with or better than QEMU’s user-mode JIT emulation.
QEMU is a weird pick here. Why not FEX?
Why is it “weird”? It has been around much longer AFAIK.
Because fex/box86 have the ability to run arm binaries linked to x86 libraries, netting signficantly greater performance. In addition to other tricks.
https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/
What’s the point of this when you can compile between ISAs using a build tool and source? When would you need to cross compile a binary after building?
Because you don’t have the source or because you can’t configure the cross-compiler
I guess I’m confused about the context you’d be in that situation.
Easy to explain: The idiot project manager skipped to set up source control, and the sources have been lost.
E.g. when you have a proprietary program that is only available on x86, but you want to run it on ARM.
Most software most people run is closed source and doesn’t have an arm version. Isn’t this the usual situation? Aunt Flo isn’t recompiling her tax filing software for arm. She just runs it, and it works because the arm laptop she has came with this built in.
I’m not talking about closed source software (heaven forfend!) but maybe you don’t have network access, or you don’t know what version you have or something. Sometimes even the best of us end up with binaries of unknown provenance that still must run.
It’s for closed source software obviously.
Isn’t going all that AI tech going to make automated decompilation trivial? Re-compiling would not need illustrative variable names…
That is basically what this does, but more reliably.


