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.
SSE wasn't available until Pentium 3, and wasn't commonly used until it was well supported by AMD as well. So the programs that require SSE will be outside of the realistic scope for emulation. MMX instructions would be more of a realistic presence, but really both it and SSE 1 map pretty decently to NEON, for the most part.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.
notaz already corrected you on the endianess. I don't know what "hacks" Wine uses and I doubt any of them would be platform specific. High level emulation of OS functions are going to be faster than low level emulation of the machine code used to implement it, almost all of the time. Unless it represents hardware that's not compatible with something you have then it should be similar to "native" speed because that's what it is, native code.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).
If you can emulate a 200MHz Pentium then there will start being some OpenGL, Direct3D, and Glide games that can meet that spec. This is at the higher end of the feasibility spectrum but I wouldn't write it off unconditionally.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.
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.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.
Calling convention is the least of your concerns when performing binary translation. Except for user mode emulation layers it's a non-issue - how the program does it internally doesn't matter.zhasha said:Admittedly I don't know how ARM passes arguments etc, however from what I read, the calling conventions are different from x86.
That's what QEMU does. What do you mean by raw power exactly? You want recompilation because it's faster, correct? Otherwise there should be no reason not to be content with interpretive emulation, which is probably better in all other ways.zhasha said:Now the goal of using LLVM would not be raw power, but more the ability to recompile to run the code natively.
Actually, static recompilation has many complications that make it less ideal than dynamic and with poorer compatibility. Indirect branch search sets can't be directly known, and while heuristics exist they may not resolve all targets and will most likely cause more code to be generated than what is branched to. Probably the more you achieve the complete target set the more false positives (and hence unused "code") you'll end up with. Dynamic loading and self modifying code can't be handled at all, which is a more fundamental issue than may be evident. If intent on storing translated executables to disk then you'd also be passing a large amount of the conversion overhead bloat to your filesystem.zhasha said:It doesn't have to be JIT; it could easily be a full recompilation + optimization.
Converting the code to LLVM and recompiling it does nothing to accomplish this. In fact, such a thing wouldn't really work because WINE operates on x86 Windows executables and would almost definitely fail to understand a Windows executable that has been converted to ARM. To do things in this order (x86 Windows -> x86 ARM -> x86 Linux) you would need a completely different WINE implementation.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.
This is a naive assumption and is most certainly not the root cause. You can't compare binary translation to backend compilation. LLVM is a language designed to facilitate compiler output, not provide an intermediary between different machine codes - it just doesn't model certain low level details well enough. Typical compiler output is actually a lot simpler than machine code and contains more useful information. You won't have this information when converting from x86 to LLVM, nor will you have something that nicely models flags and other machine behavior in a way that LLVM's ARM code generator can use. Full program optimization is nice at a high level, but when you're dealing with machine code most of the important context is sitting in registers that will usually have a limited liveness window for any particular allocation. Besides that, you can recompile adaptively to achieve a lot of "whole program" like optimizations, and you can recompile greedily to achieve things like inlining.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.
But so is using QEMU/WINE, and it's a solution where much more of the work is already done. In fact, it might be possible to run it in this manner right now, without any coding being necessary. Someone should try it.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.
Hm, I wouldn't count on most people agreeing with you, maybe in recent years some big name games have been ported but that isn't relevant. We're talking about games that ran on mid to late 90s PC hardware, how many of those were ported to Linux? Or do you think all of them are bad..?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