<div>Thanks everyone for their comments. I took some time to reread the FX!32 and Transmeta Crusoe publications (I 1st read them 3 years ago while I was at Georgia Tech) to see what the challenges are.</div><div><br></div>
<div>The simplest approach is what Stefan proposed:  run the Windows app inside x86 wine, inside of QEMU (target = x86, host = arm). Pretty clever, but the 2 layers of translation, instead of 1 layer, might cause problems. Also, I said earlier, I don&#39;t think QEMU&#39;s code generator produces fast enough code, so that will need to be improved (no change to Wine). I will try it and see what happens.</div>
<div><br></div><div>The 2nd approach, which is almost identical to FX!32 (runs x86 Windows programs on Alpha Windows), will be to do what Stefan proposed 2nd:  create a stand alone process VM to run x86 Windows apps on ARM Windows, using wrappers to translate x86 Windows functions to ARM Windows functions. I think those wrappers/jackets can be generated automatically by scanning header files.</div>
<div><br></div><div>I still don&#39;t like this approach due to doing the API translation and instruction set translation in 2 separate programs. Ideally, I would take the Darwine approach of doing both API translation and binary translation both in Wine.</div>
<div><br></div><div>To me, the API translation is less interesting than doing x86 to ARM translation efficiently. I said earlier, QEMU&#39;s approach of translating target instructions =&gt; micro ops =&gt; host instructions is inefficient due to generating redundant operations.</div>
<div><br></div><div>1. Transmeta code morphing software</div><div>       no emulation of x86 instructions: always translates to native instructions (though not always with optimizations). Hot code is retranslated with optimizations.</div>
<div>2. FX!32</div><div>       first emulates x86 instructions, then picks candidates for translation to Alpha instructions</div><div><br></div><div>I&#39;m tempted to do a quick and dirty x86 to ARM translation for cold code that isn&#39;t a candidate for optimization. But since any non-trivial code transformation/optimization is best done on a *simple* intermediate representation, I will have use an intermediate representation for hot code that needs to be optimized.</div>
<div><br></div><div>But writing a direct x86 to ARM translator will be a lot of work and not portable to other targets (resurgent MIPS ?)</div><div><br></div><div>Therefore, another approach would be to use QEMU as is, but use LLVM optimizations for hot candidates like was done earlier in a Google SOC project. This will be very slow on a the 1st run of the program, but a persistent translation cache like FX!32 and .NET assembly uses, will make subsequent executions much faster. The static persistent translation won&#39;t be complete however, due to unknown indirect branches, so it will keep growing. I think the main reason FX!32 uses a persistent translation cache is because it uses emulation, which would be otherwise intolerable if done on every application launch.</div>
<div><br></div><div>Other issues:</div><div><br></div><div><div><div>x86 condition flag evaluation - I want to do this lazily, but how do I know the liveness of those values (given an instruction that uses a condition flag, how do I find the instruction that generates the condition flag)?</div>
</div><div><br></div></div><div><br></div><div>Stefan, ---------------------------------------------------------------------------------------------</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&quot;ARM doesn&#39;t need [dealing with unaligned loads/stores], but PPC does&quot;</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">OK, good to know. Earlier, I thought ARM didn&#39;t allow unaligned loads/stores at all, but apparently ARM6+ does.</span></font></div>
<div><br></div><div>Andre, -----------------------------------------------------------------------------------------------</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&quot;</span><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Maybe first to ARM Linux and then to ARM Android?&quot;</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Yes, if I can figure out how to install Ubuntu onto my Xoom. I saw someone do it <a href="http://www.youtube.com/watch?v=xDB0PMrGdN0">here</a>, but he&#39;s just running the userspace part of Ubuntu on top of Android, so I&#39;m not sure if that will be as compatible as running a native Linux kernel</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&quot;I know about that and was told it was never implemented because of problems with the endianess&quot;</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Right, if the endians are different and required byte swapping on every load/store, that will kill the performance. Luckily ARM</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">can operate in both little and big endian.</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div>Damjan,<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; "> -------------------------------------------------------------------------------------------------</span></div>
<div><br></div>In theory, binary translation will allow Flash Player, Java JVM, to run on ARM, but there might be complications because those programs generate and execute x86 code.<br><br><div><div>Also, I agree improving QEMU binary translation would be the simplest approach, but like I said earlier, I get a feeling that doing API translation and instruction set translation in 2 separate programs,</div>
<div>might cause problems.</div><div><br></div><div><div><br></div><div>                    Yale</div></div><div><br></div><div><br><div class="gmail_quote">On Sat, Apr 2, 2011 at 9:06 AM, Damjan Jovanovic <span dir="ltr">&lt;<a href="mailto:damjan.jov@gmail.com" target="_blank">damjan.jov@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Sat, Apr 2, 2011 at 2:19 AM, Yale Zhang &lt;<a href="mailto:yzhang1985@gmail.com" target="_blank">yzhang1985@gmail.com</a>&gt; wrote:<br>




&gt; Fellow developers,<br>
&gt; I&#39;m thinking of starting a VM project to allow running x86 Windows apps on<br>
&gt; ARM Android. This will obviously involve binary translation. I&#39;ve read about<br>
&gt; QEMU&#39;s  tiny code generator and think for a usable experience,<br>
&gt;  the intermediate micro-op representation will have to be abandoned, and use<br>
&gt; a more efficient, though less portable x86 to ARM translator. I also saw<br>
&gt; some Google SOC project that tried to incorporate LLVM into QEMU, but with<br>
&gt; disastrous slow down if done naively. I still think it&#39;s worth to do so, but<br>
&gt; lots of care will need to be done to only optimize code that needs it like<br>
&gt; Sun&#39;s HotSpot Java compiler does.<br>
&gt; Questions:<br>
&gt; 1. How useful would this be and how much interest?<br>
&gt;    Obviously, this will be a huge project, and I just want to gauge the<br>
&gt; interest before I jump in. Microsoft will be releasing Windows for ARM soon,<br>
&gt; so there will be no need to worry about<br>
&gt;    running Office, Matlab, Visual C++, etc on ARM, leaving only legacy<br>
&gt; applications and games to benefit from binary translation. I&#39;m mostly<br>
&gt; interested in seeing some 3D games run on my<br>
<br>
</div>I would love such a project and am willing to help. Good x86 on ARM<br>
emulation is essential, and not just for Wine: Flash doesn&#39;t work on<br>
ARM, Java (in the form of OpenJDK) doesn&#39;t support ARM yet, there&#39;s<br>
the MPlayer win32codecs, etc.<br>
<br>
Complete and correct x86 emulation is mighty difficult. The total<br>
number of all 16/32/64/MMX/SSE instructions (as seen by the udis86<br>
disassembler) is 710(!!). This is excluding instruction prefixes which<br>
change what instruction do (eg. 16 vs 32 bit memory access). When last<br>
I checked, qemu didn&#39;t support all of those instructions.<br>
<div><br>
&gt;    Xoom.<br>
&gt; 2. What&#39;s the best design:  whole system VM (qemu) or process VM (qemu &amp;<br>
&gt; wine)?<br>
&gt; Process VM:<br>
&gt; + easier to incorporate 3D acceleration at API level<br>
&gt; + uses less memory<br>
&gt; + better performance (e.g. no need for MMU translation when accessing<br>
&gt; memory)<br>
&gt; + much better integration with host OS<br>
&gt; - needs to maintain custom Windows API implementation (Wine)<br>
<br>
</div>* To get 3D acceleration, user-space x86 X/OpenGL drivers would have<br>
to be able to talk to the ARM kernel driver for that graphics card, or<br>
you&#39;d need x86 to ARM wrappers for X and OpenGL libraries, or you&#39;d<br>
need to use x86 kernel driver and do x86 emulation in the kernel too<br>
(very hard), or do whole system VM and the kind of 3D acceleration<br>
passthrough that VirtualBox does at the moment (which works poorly, in<br>
my limited experience). NVidia&#39;s ioctls are undocumented IIRC, so even<br>
if they provide an ARM port, translating those between x86 and ARM<br>
might be difficult.<br>
<div><br>
&gt; Whole system VM:<br>
&gt; + simpler, more unified to implement<br>
&gt; + much better support for apps that are dependent on new, proprietary,<br>
&gt; obscure Windows libraries, interfaces    (moot because Office, Matlab, etc<br>
&gt; will soon be available for ARM)<br>
<br>
</div>* poor integration with native desktop/filesystem<br>
* more to emulate -&gt; slower<br>
<div><br>
&gt; Given the aims of only running legacy applications and games, it seems a<br>
&gt; foregone conclusion that Wine&#39;s process VM approach is best. Comments?<br>
<br>
</div>Agree, but it doesn&#39;t have to be done as part of Wine. What Darwine<br>
did - IIRC try to make Wine DLLs PowerPC based and only the<br>
application x86 - seems like a bad idea: the application/Windows API<br>
split is badly defined and many things (eg. COM) are<br>
difficult/impossible to do correctly. I prefer qemu&#39;s approach: all<br>
user-space is x86, only the kernel is ARM.<br>
<br>
qemu-i386 doesn&#39;t even run 32 bit Wine on amd64 long mode at the<br>
moment (segfault on startup), I&#39;ll have to investigate at some stage.<br>
<div><br>
&gt; 3.  Will Wine ever incorporate binary translation?<br>
&gt;    My proposed design will obviously use Wine&#39;s implementation of the<br>
&gt; Windows API, which is huge. I&#39;m not sure how disruptive of a change binary<br>
&gt; translation will be to Wine.<br>
&gt;<br>
&gt;    If Wine does incorporate binary translation, maybe they can change the<br>
&gt; name to Wine Is Now an Emulator<br>
&gt;<br>
&gt; If your&#39;re interested in this project, please reply.<br>
<br>
</div>Replying.<br>
<br>
The best way to go here would probably be improving qemu. If it turns<br>
out not to be good enough, rewriting the CPU emulation but keeping the<br>
system call translation is probably easier than a whole new project<br>
written from scratch.<br>
<font color="#888888"><br>
Damjan<br>
</font></blockquote></div><br>
</div>
</div>