Hacker News Reader

Actually, the performance might not be as bad as you would at first think. A good chunk of the work done by a graphical application is actually done by the graphics system supplied by the "OS", and in this case, that code would be natively compiled.

It's analogous (performance-wise) to writing gui apps in python - provided you're not trying to do any heavy lifting in the actual application code, it could work quite well.

Apple's Rosetta technology for running PowerPC code on Intel Macs actually worked this way, and the performance for most apps was really quite acceptable. That said, Rosetta had the advantage of moving from relatively slow CPUs to the fastest in the world. In the case of ARM / Android, you would be trying to run Windows apps on a slower CPU, so the results wouldn't be as good as Rosetta...

I agree with everything you have said. I would just add that I think many of the most useful (and widely used) Windows applications do do heavy lifting in native code — Word, Excel, and Photoshop are all good examples here. They aren't explicitly number-crunching like BTC mining or SETI@Home, but there is a lot of x86 code running under the hood.

>Another commenter says that the project wiki suggests using qemu to run the x86 code on ARM, and then trap calls into native (ARM) WINE libraries. This approach seems unlikely to yield good performance. I am concerned that different C and C++ calling conventions means some additional work will have to be done to cleanup function arguments at every call, which is just more overhead on top of x86 emulation…

There is already similar project about running x86 windows application on top of Windows RT:

http://forum.xda-developers.com/showthread.php?t=2095934

It will be interesting to compare.

>>>So maybe WINE on ARM can serve to run WinRT applications

That would be a trick: How do you buy RT apps when not on a Microsoft-approved device?

Good question. I am not actually familiar with the specifics of WinRT; I haven't touched Windows regularly since the early 2000s.

Maybe you first buy them on a MS-approved device and either copy the app from that device or are able to get a DL link that works on the other device.

But that would make you buy what you want to avoid -- an MS-approved device.

Not everyone who wants to run RT apps on non-MS devices is trying to avoid MS in every aspect of their lives.

But Wine on x86 Android would be useful.

Sure, but then it's just normal WINE. Not WINE on ARM, which is suggested by the article =).

What we need is an x86 emulator that JIT compiles the x86 code to ARM.

Which is exactly what qemu does. Although there is significant space for optimizing the host code produced by qemu.

Cross-architecture compilation is ridiculously hard, and the balance between JITing the code and the resulting code's speed is very, very fine, and often depends per process: you don't know when translating an executable page how much it might be run. It could never execute or it could execute trillions of times. You can't just translate every bit of executable code because you WILL spend more time translating than executing. On the other hand, you need to translate well enough that you have good cache performance, make good use of registers (some are usually reserved for emulation state), and the extremely nasty bit of translating specialized math instructions and SIMD instructions, which often have implementation-specific nastiness that causes issues if you translate naïvely. Add onto that fundamental differences that always arise (e.g. unaligned/aligned loads, memory protection/translation differences/access modes, debug/performance registers, appropriate clock timing when necessary, hardware access.... it's endless) and you find yourself relying on pretty horrific hacks to avoid bad performance.

In short, unless you have specialized hardware for this (Transmeta!) it's going to be a massive undertaking.... so if you're confused by the host code produced by qemu, it's a lot harder to produce than you might think, although the primary reason is that producing better code often is not worth it because of the translation time. There may have been recent work to move some of the research in PL JIT over to translation, e.g. progressively translating better code the more it's run, but I haven't looked in a while.

In my view what qemu produces is perfectly acceptable. On the other hand applying optimization approach of Java's HotSpot or Python's PsyCo to qemu might be interesting. (and something like that was already done by HP's Dynamo which could "emulate" parisc code on parisc faster than direct execution)

Still architecture differences are significant, but in this case for what you really want to accomplish ARM is reasonably similar to i386.