5 ms·

Please note that you can kind of already do this using qemu on both windows and linux.

lunixbochs 10y ago
You can do this in the 99% case on Linux using qemu-user, but I'm not aware of an equivalent for Windows (and booting an entire operating system in an emulator is a poor experience and will be even slower). I imagine this Windows variant works like qemu-user and Rosetta. QEMU has some bad performance penalties, I think partially related to the generic JIT (TCG), extremely strict floating point, and full host memory isolation. ExaGear is significantly closer to native performance but I think only supports emulating 32-bit x86.
- zeta0134 10y ago
  This is a trade-off with any emulation really. The more hardware accurate your emulation gets, the more you have to keep track of in virtual registers and state, and all that extra tracking adds up in a hurry. Native virtualization dodges a lot of that performance penalty by using the hardware features directly where possible. But that's only really feasible on systems that have nearly identical hardware; x86 is pretty standardized at this point and virtualizes quite well. ARM is much more varied and harder to virtualize, even on other ARM platforms due to differing feature sets.
  - lgeek 10y ago
    It's not that in this case, this is plain binary translation and not cycle accurate emulation. QEMU is super slow on x-to-x translation as well (something like 8x to 80x slowdown). Its translator is inefficient (for the sake of portability, the source native code is first translated to an IR and then the IR is compiled to target native code with limited optimisation) and it emulates all floating point instructions in software.
    - john_reel 10y ago
      How does it handle polymorphic code?
- lgeek 10y ago
  And these guys ship an x86 to ARM DBT which they claim has significantly better performance: https://eltechs.com/product/exagear-desktop/ https://eltechs.com/product/exagear-desktop/. I haven't tried it. QEMU is the slowest DBT system I'm aware of, so it's entirely plausible. Translating from a strongly ordered architecture to a weakly ordered architecture is big challenge, I wonder if they handle threads efficiently.
colejohnson66 10y ago
The way I understand it is that it would be transparent to the user like Rosetta was on Intel Mac OS X a while back.
- rwmj 10y ago
  qemu-user can already do that too. On Linux you have to put a magic string into an /etc/binfmt.d file (on Fedora at least, the qemu-user package does that for you). Here's running aarch64 binaries on x86_64 transparently: https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x86-64-host-using-qemu-userspace-emulation/ https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-bin...
  - basch 10y ago
    isnt that backwards? this is x86 code on arm devices.
    - jdub 10y ago
      Works the same way with numerous combinations of architectures, thanks to qemu.

You can do this in the 99% case on Linux using qemu-user, but I'm not aware of an equivalent for Windows (and booting an entire operating system in an emulator is a poor experience and will be even slower). I imagine this Windows variant works like qemu-user and Rosetta. QEMU has some bad performance penalties, I think partially related to the generic JIT (TCG), extremely strict floating point, and full host memory isolation. ExaGear is significantly closer to native performance but I think only supports emulating 32-bit x86.

zeta0134 10y ago
This is a trade-off with any emulation really. The more hardware accurate your emulation gets, the more you have to keep track of in virtual registers and state, and all that extra tracking adds up in a hurry. Native virtualization dodges a lot of that performance penalty by using the hardware features directly where possible. But that's only really feasible on systems that have nearly identical hardware; x86 is pretty standardized at this point and virtualizes quite well. ARM is much more varied and harder to virtualize, even on other ARM platforms due to differing feature sets.
- lgeek 10y ago
  It's not that in this case, this is plain binary translation and not cycle accurate emulation. QEMU is super slow on x-to-x translation as well (something like 8x to 80x slowdown). Its translator is inefficient (for the sake of portability, the source native code is first translated to an IR and then the IR is compiled to target native code with limited optimisation) and it emulates all floating point instructions in software.
  - john_reel 10y ago
    How does it handle polymorphic code?
lgeek 10y ago
And these guys ship an x86 to ARM DBT which they claim has significantly better performance: https://eltechs.com/product/exagear-desktop/ https://eltechs.com/product/exagear-desktop/. I haven't tried it. QEMU is the slowest DBT system I'm aware of, so it's entirely plausible. Translating from a strongly ordered architecture to a weakly ordered architecture is big challenge, I wonder if they handle threads efficiently.

colejohnson66 10y ago

The way I understand it is that it would be transparent to the user like Rosetta was on Intel Mac OS X a while back.

rwmj 10y ago
qemu-user can already do that too. On Linux you have to put a magic string into an /etc/binfmt.d file (on Fedora at least, the qemu-user package does that for you). Here's running aarch64 binaries on x86_64 transparently: https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x86-64-host-using-qemu-userspace-emulation/ https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-bin...
- basch 10y ago
  isnt that backwards? this is x86 code on arm devices.
  - jdub 10y ago
    Works the same way with numerous combinations of architectures, thanks to qemu.