Project: x86 to ARM binary translator

[Damjan Jovanovic]

On Sat, Apr 2, 2011 at 2:19 AM, Yale Zhang <yzhang1985 at gmail.com> wrote:
> Fellow developers,
> I'm thinking of starting a VM project to allow running x86 Windows apps on
> ARM Android. This will obviously involve binary translation. I've read about
> QEMU's  tiny code generator and think for a usable experience,
>  the intermediate micro-op representation will have to be abandoned, and use
> a more efficient, though less portable x86 to ARM translator. I also saw
> some Google SOC project that tried to incorporate LLVM into QEMU, but with
> disastrous slow down if done naively. I still think it's worth to do so, but
> lots of care will need to be done to only optimize code that needs it like
> Sun's HotSpot Java compiler does.
> Questions:
> 1. How useful would this be and how much interest?
>    Obviously, this will be a huge project, and I just want to gauge the
> interest before I jump in. Microsoft will be releasing Windows for ARM soon,
> so there will be no need to worry about
>    running Office, Matlab, Visual C++, etc on ARM, leaving only legacy
> applications and games to benefit from binary translation. I'm mostly
> interested in seeing some 3D games run on my

I would love such a project and am willing to help. Good x86 on ARM
emulation is essential, and not just for Wine: Flash doesn't work on
ARM, Java (in the form of OpenJDK) doesn't support ARM yet, there's
the MPlayer win32codecs, etc.

Complete and correct x86 emulation is mighty difficult. The total
number of all 16/32/64/MMX/SSE instructions (as seen by the udis86
disassembler) is 710(!!). This is excluding instruction prefixes which
change what instruction do (eg. 16 vs 32 bit memory access). When last
I checked, qemu didn't support all of those instructions.

>    Xoom.
> 2. What's the best design:  whole system VM (qemu) or process VM (qemu &
> wine)?
> Process VM:
> + easier to incorporate 3D acceleration at API level
> + uses less memory
> + better performance (e.g. no need for MMU translation when accessing
> memory)
> + much better integration with host OS
> - needs to maintain custom Windows API implementation (Wine)

* To get 3D acceleration, user-space x86 X/OpenGL drivers would have
to be able to talk to the ARM kernel driver for that graphics card, or
you'd need x86 to ARM wrappers for X and OpenGL libraries, or you'd
need to use x86 kernel driver and do x86 emulation in the kernel too
(very hard), or do whole system VM and the kind of 3D acceleration
passthrough that VirtualBox does at the moment (which works poorly, in
my limited experience). NVidia's ioctls are undocumented IIRC, so even
if they provide an ARM port, translating those between x86 and ARM
might be difficult.

> Whole system VM:
> + simpler, more unified to implement
> + much better support for apps that are dependent on new, proprietary,
> obscure Windows libraries, interfaces    (moot because Office, Matlab, etc
> will soon be available for ARM)

* poor integration with native desktop/filesystem
* more to emulate -> slower

> Given the aims of only running legacy applications and games, it seems a
> foregone conclusion that Wine's process VM approach is best. Comments?

Agree, but it doesn't have to be done as part of Wine. What Darwine
did - IIRC try to make Wine DLLs PowerPC based and only the
application x86 - seems like a bad idea: the application/Windows API
split is badly defined and many things (eg. COM) are
difficult/impossible to do correctly. I prefer qemu's approach: all
user-space is x86, only the kernel is ARM.

qemu-i386 doesn't even run 32 bit Wine on amd64 long mode at the
moment (segfault on startup), I'll have to investigate at some stage.

> 3.  Will Wine ever incorporate binary translation?
>    My proposed design will obviously use Wine's implementation of the
> Windows API, which is huge. I'm not sure how disruptive of a change binary
> translation will be to Wine.
>
>    If Wine does incorporate binary translation, maybe they can change the
> name to Wine Is Now an Emulator
>
> If your're interested in this project, please reply.

Replying.

The best way to go here would probably be improving qemu. If it turns
out not to be good enough, rewriting the CPU emulation but keeping the
system call translation is probably easier than a whole new project
written from scratch.

Damjan