Moderator: Moderator Team
Bblaauw wrote:Whenever no native port of ReactOS to ARM, QEMU emulating x86 on this ARM board should allow ReactOS to barely run.
Getting a no-nonsense Linux that only starts QEMU, is another matter.
FlyingIsFun1217 wrote:Bblaauw wrote:Whenever no native port of ReactOS to ARM, QEMU emulating x86 on this ARM board should allow ReactOS to barely run.
Getting a no-nonsense Linux that only starts QEMU, is another matter.
And what host would be running Qemu?
EmuandCo wrote:Wtf are you talking? You can't simply port a runtime or pray that a executable does not use any assembler, because the compiler generates this assembler. You are not able to run any built app inside any strange architecture just by trying to call any strange ported API calls. whoever told you that should really read some stuff or ask and not claim absolutely wrong stuff...
From the Wine Wiki Page for ARM: Run the assembler parts of x86 in qemu and call function in Wine compiled for ARM, which might speed up some things (darwine tried that before, but they stopped because the byteswapping (big endian <-> little endian) was too much work, but ARM is mostly little endian, so we have a chance if everything works fine with packed structures.)
From the WINE Forums: The means to run dll code native arm and application inside x86 emulation could reduce a lot of the performance bloat issue. Yes this would be a huge undertaking. (Translation: Run code that calls other DLL's or Functions in Win32/Wine/Windows from native compiled DLL's, run x86 specific code under QEMU)
There is an effort to port Wine to the ARM platform. The problem is like that for the Mac PowerPC platform, you will need a CPU emulator
until Windows programs start to appear for the target platform. Running an emulator AND a bloated Windows program may prove to
slow for ARM processors as it did for the PowerPC platform.
Winelib is ported to ARM, just a few things missing but nothing critical. The problem on PowerPC was mostly the endianess, not the speed
Everyone forgets about qemu usermode emulation. One of the most advanced forms of paravirtualization. Of course current qemu usermode emulation is limited. It emulates at the syscall to kernel point. So every time application does a syscall the syscall is processed natively.
To make wine more possible on arm expanding this usermode emulation would be required. Very much like x32 interfacing with 64 bit code. So that library calls inside qemu could be processed outside in platform native code. So reducing the performance damage from emulation even introducing AOT(ahead of time processing) instead of JIT that qemu uses could assist.
Currently Qemu userspace operation is that it receives a system call request from a contain Linux application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers. Currently Qemu userspace operation is that it receives a system call request from a contain Linux application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers. Wine could use its own custom syscalls to call for operations processed outside in arm then have data returned to the virtualization. http://wiki.qemu.org/download/qemu-doc. ... e-emulator This is the documentation on the usermode emulation
From OpenHandhelds: Would it be possible to run windows application(games) using qemu for x86 to arm translation and wine for the windows api? (Note: Information below comes from "Exophase" who is described as "an emulation Guru")
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.
There are things that x86 programs do routinely that don't map directly to ARM. This includes memory operands (especially destination, ie read-modify-write instructions or RMW), call/ret which pushes/pops the stack, 8/16bit operations, 32bit immediate operands and address offsets, and some flag mismatches. These things mean that some x86 instructions will convert to two or more ARM instructions. With this conversion you would get results like what M-HT has with his static recompilation, which for his tests were 40-50% native. The thing is, ARM can do many things that x86 can't. It has three operand arithmetic and folded shifts which can eliminate a move or a shift instruction in x86 under relatively common circumstances. It has conditional execution which can eliminate small one armed (and sometimes two armed) if statements that got converted to branches. It has more registers which could possibly map to fixed locations on the stack eliminating some memory accesses. It has load/store multiple instructions which could fold sequences of load/store instructions on x86. Pre-post increment/decrement can also be folded into memory accesses. With aggressive optimization I would imagine that you can improve the performance of translated code by a noticeable amount.
Let me talk a little bit about what I called "user mode emulation" and why it allows for much better performance. Obviously OS HLE can improve things, like I mentioned, but there are two main things that make the burden of machine code emulation lighter than it is for full blown "system emulation." One is that you don't have to emulate physical device access, which means that the address space just consists of memory. Since the OS usually abstracts memory in some way you just need an OS on the other end that's compatible with what the program expects. In some cases it's even possible to arbitrarily relocate the program entirely. Memory emulation is one of the biggest drains in system emulation and being able to reduce it to native accesses improves things dramatically. The other benefit is that you don't have to emulate interrupts, meaning that you don't have to count cycles and abort when they run out. Cycle counting is both a performance drain and a pain to work with while allowing the code to be optimized.
The down side to all this is that you must emulate the OS at a high level. Fortunately, Wine is already doing exactly that.
(post)"It is possible to run windows programs in Linux on ARM but it takes more than just wine. Way back, when the Sharp Zaurus was big news some people managed to combine wine and qemu. Qemu was providing the processer emulation while wine provided the windows libraries. If you search you may still be able to find a tutorial about how to make that work. I have no idea what to expect performance wise but it would be an interesting experiment."
Now the goal of using LLVM would not be raw power, but more the ability to recompile to run the code natively. That's what QEMU does.
BrentNewland wrote:This is a cheap and easy way to get ReactOS ported to ARM processors
Z98 wrote:Nothing that requires time and manpower to accomplish is "cheap" and "easy." The existence of the raspberry does not magically make the actual writing of code for ARM easier.