Not a chance. Do you know how much boilerplate you need to use the most basic libraries in Windows?mindlord said:Maybe, if you're lucky you'll be able to play solitaire.
Well, if you say so, it must be rightExophase said:I disagree with the basic sentiment of the responses on this thread. Qemu's userspace x86 to ARM translation as it stands now should be much more efficient than the ARM recompiler currently present in DOSBox, which is very slow. Userspace emulation has its own simplifications that lead to faster code and Windows programs will be higher level/spend more time in driver code (especially for 3D things) that would run more quickly due to being emulated at a high level.
Qemu is probably capable of performing around a 15-20% native speed for typical applications, so a 50-100MHz Pentium 1 wouldn't be completely out of the question. I personally believe that userspace x86 emulation can do much better. I expect an average of over 50% native speed to attainable. M-HT's static recompiler is doing 40-50% on one test application and I believe that more aggressive optimization can have significant gains.
dflemstr said:Well, if you say so, it must be right
I was more under the impression that
1. Many x86-instructions, primarily SSE-related things, would represent a very large number indeed (say, 15) of matching ARM instructions to perform the same operation.
dflemstr said:2. Many of the performance hacks used in the winelibs would be plain inefficient and might actually slow stuff down, since we're dealing with two completely different architectures with different endianness etc that will require a good heap of translation to make them work together, and where you can't use tricks like shared memory and whatnot (I don't really know much about this stuff to be honest).
dflemstr said:EDIT: @Mindlord Wine already has OpenGL wrappers and DX-OGL translation so this shouldn't be an issue, at least if we get some kind of OGL2 compatibility library around the current OGLES2 driver on the Pandora. It will be slow, too, of course.
urjaman said:Given that if it works (i didn't get it to work sometime back, but i'm hoping that somebody will), the qemu+wine approach that is currently feasible is essentially that arm-qemu runs (emulates CPU and translates kernel calls) x86-wine(+x86 linux libs) which runs x86-windows-app (and x86 windows libs)
- this ofcourse makes things much easier (and faster) than full system emulation (no need to emulate kernel code & hardware etc)
- but performance-wise i would like to see a much more optimized case of arm-wine (arm libs) + qemu + x86-win-app ...
- maybe even so that the free wine libs would be compiled for arm and only the x86 application would be emulated by qemu which would need to translate between x86-windows and ARM-linux ABI calls (between arm wine libs and the x86 app) (and x86 windows kernel calls to arm-wine).
- This would allow even the wine DirectX to OpenGL translation layer to run natively - although it would need to be modified to be a DirectX to OGL ES layer.
This all would ofcourse require lots and lots of work and pretty much a fusion of wine and qemu, so for now it's just a dream...
That's from my point of view the main benefit from high-level simulation of the OS.Exophase said:Memory emulation is one of the biggest drains in system emulation and being able to reduce it to native accesses improves things dramatically.
Even for x86 on x86, OpenGL calls are going through a wrapper in Wine due to calling conventions being different. That can become a problem, since many OpenGL calls are basically doing nothing and you end up spending a measurable amount of time wrapping calls.Exophase said:That would ultimately be the best course of action, but I wonder how much overhead the Wine translation costs in typical applications. I would suppose that you'd need Linux OGL to OGL ES translation (we already have something like that that can be used, from a few sources) for Linux to Linux translation.
zhasha said:Admittedly I don't know how ARM passes arguments etc, however from what I read, the calling conventions are different from x86.
zhasha said:Now the goal of using LLVM would not be raw power, but more the ability to recompile to run the code natively.
zhasha said:It doesn't have to be JIT; it could easily be a full recompilation + optimization.
zhasha said:The idea is to eliminate the need for any layer between WINE and the application, or changes to WINE that aren't purely because of compilation/runtime issues - not cross-arch related.
zhasha said:In the case of qemu-llvm, I can imagine that a large performance hit would come from not having all the application code at start time, thus you can't optimize as agressively.
zhasha said:The only remaining piece of the puzze would be the x86 frontend for LLVM, which is a huge piece of work - then comes all the stability/optimization work of course.
I'm not at all saying this is a good idea, I'm just saying it's a solution.
zhasha said:The idea of running x86 binaries on an ARM processor is ridiculous enough in itself, let alone binaries from Windows. All the good games have been ported anyway