Project: x86 to ARM binary translator

Yale Zhang yzhang1985 at gmail.com
Fri Apr 1 19:19:33 CDT 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110401/c5cf5311/attachment.htm>


More information about the wine-devel mailing list