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:
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.
- 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?
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