Project: x86 to ARM binary translator

[Charles Davis]

On 4/1/11 6:19 PM, Yale Zhang 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
>    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)
> 
> 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)
> 
> Given the aims of only running legacy applications and games, it seems a
> foregone conclusion that Wine's process VM approach is best. Comments?
> 
> 
> 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.
I'm not competent enough to mentor you, but, being a Mac user, I have a
story to tell you. It's about a version of Wine that did incorporate
binary translation: Darwine. Darwine was separate from mainline Wine; it
incorporated QEMU directly and used it to translate x86 to PowerPC code.
In a faraway time when Macs used PowerPC CPUs, Darwine allowed x86
Windows apps to run on Mac OS X. Now that Macs aren't built PowerPC
chips anymore, Darwine has been abandoned. You might consider using it
as a starting point, though.

I switched over to the Mac platform (from Windows) in 2007, well after
the PPC->x86 transition began, so I never needed Darwine. I did hear
however that Darwine had major problems getting good performance (just
as you surmised). You might have better luck rolling your own x86->ARM
translator after all.

That said, I'm also an LLVM guy, so I hear things like people proposing
to modify LLVM's JITter to be adaptive (i.e. to heavily optimize
heavy-traffic areas only), just as you propose. If that goes through,
you might have better luck integrating LLVM into QEMU (again), then
basing your project off of Darwine.

Chip