Can The Pandora Run A Virtual Machine?

[Exophase]

Linux to Linux usermode CPU emulation (x86 Linux executable to ARM Linux executable) then Windows emulation via WINE is the easiest migration path if it can work at all.

Moving to ARM WINE + user mode emulation combined together is a logical improvement but it's not a small amount of engineering. It probably wouldn't win you much if your binary translation is any good because you'd only be improving the performance of the wrapper code from Windows to Linux.

Emulating a Windows PC directly via QEMU is an inferior solution for a number of reasons.

1) It requires system mode emulation which removes a lot of assumptions you can make about the platform. Worst is that you can't use the host's address space abstraction to allocate memory since you must be in control of the whole 4GB. It also means having to emulate things like implicit segments (CS/DS/ES/SS) for all memory accesses. System mode emulation also requires emulating a lot more instructions that aren't normally used in user applications so it's a lot more work.

2) You have to emulate the whole PC at a low level, which puts a lot more processing burden on providing things like video cards, sound cards, harddrives, etc instead of providing high level interfaces to these resources.

3) You have to emulate the OS's functionality at a low level instead of at a high level which has a greater processing burden as well.

4) QEMU isn't at the pinnacle of binary translation performance. If you only have to worry about writing a user mode binary translator and don't have to emulate any system mode functionality, hardware, or even memory, then writing a new x86 to ARM dynamic recompiler is not that much work and more effort can be spent on optimizing it. The requirements shouldn't be much different from M-HT's static recompiler, which attains 40-50% native speed on at least one test and contains almost no analytical optimization save for flags. This should give an indication of what you can achieve relative to QEMU's current performance.

Translating from x86 Linux to ARM Linux should be relatively straightforward, at least for getting enough software going. Translating from OGL to OGL ES may be another story, but we do have people working on wrappers right now.

 

[elwing]

or we can simply stick to dosbox as i doubt lot of more recent x86 apps would run trough qemu+wine...

 

[JayFoxRox]

I think recompiling before the application even starts would be an option.
You wouldn't want to have high-compatibility anyway because the Pandora isn't powerful enough to run many good x86 titles which don't work in dosbox.
Therefore it would make a lot more sense to only recreate these functions, which are required by popular software which has the chance of running on the Pandora.
I think porting wine is a huge task (//Edit: as-in making it OpenGL ES (and other APIs) ready - maybe this is also moved to the qemu front, depends on how you start: either merging qemu and wine or just using qemu to run wine), and getting qemu to a good state is also hard. Writing your own from scratch for - lets say - 5 titles would be easier imo.

 

[Esn]

or we can simply stick to dosbox as i doubt lot of more recent x86 apps would run trough qemu+wine...

I'm personally hoping that it would allow some games to run which are a little beyond DOSBox's range (486/early Pentium games), as those games generally could run in either DOS or Windows, and apparently there's more chance of running them under Windows on Pandora than under DOS (that's what I was told here earlier by someone who seemed to know what he was talking about, anyway).

My hope is for Star Control 3 to be playable - others have their own hopes...

 

[Exophase]

or we can simply stick to dosbox as i doubt lot of more recent x86 apps would run trough qemu+wine...

DOSBox for ARM is currently extremely slow for protected mode applications. You're lucky to get over 1% native speed. Are you really happy settling for that? Do you really think there's no worthwhile room for improvement?

People doubt a lot of things but sometimes they're just supporting the status quo.

Then again, I did say forget QEMU as well, but at least it's faster than DOSBox.

 

[PhonicUK]

With all the talk of QEmu, I'd just like to point out that QEmu for ARM hosts is not working properly at the moment.

http://www.nongnu.org/qemu/status.html

And if we're talking about Windows games under Linux, as has long been known the best way would be to run WINE using QEmu-User directly instead of having an entire OS running. This is the only way any usable results will be had, since much of the processor time is taken up in the kernel and underlying system than in the application itself.

Also remember, QEmu is a dynamic recompiler, not a virtualizer.

 

[lingenfr]

I've got to admit that I don't get the role/relationship of qemu and wine. Is there a good explanation anywhere?

 

[lulzfish]

I think they mean something like this:

Pandora [ARM] runs Qemu to emulate some small Linux distro [x86]
Small Linux distro [x86] runs WINE to not emulate Windows [x86]

Windows runs Windows program incredibly slowly.

edit: yeah, it's userspace, so:

Windows calls are translated to Linux stuff by WINE,
then Qemu translates WINE into ARM stuff.

No extra Linux kernel... I clearly was not paying attention.

 

[PhonicUK]

I think they mean something like this:

Pandora [ARM] runs Qemu to emulate some small Linux distro [x86]
Small Linux distro [x86] runs WINE to not emulate Windows [x86]

Windows runs Windows program incredibly slowly.

Profit.

No that's not how it works.

QEmu supports User-Space emulation - Meaning that instead of emulating an entire virtual machine complete with OS, you can run Linux binaries for one platform on another - the x86 instructions would be dynarec'd and it would use system call translation for calls to libraries.

So WINE would run under QEmu-User. No need for a 2nd version of Linux to be running.

This was the mechanism originally used by the Darwine project to run x86 WINE on PPC machines.

 

[ldesnogu]

QEMU isn't at the pinnacle of binary translation performance. If you only have to worry about writing a user mode binary translator and don't have to emulate any system mode functionality, hardware, or even memory, then writing a new x86 to ARM dynamic recompiler is not that much work and more effort can be spent on optimizing it. The requirements shouldn't be much different from M-HT's static recompiler, which attains 40-50% native speed on at least one test and contains almost no analytical optimization save for flags. This should give an indication of what you can achieve relative to QEMU's current performance.

40-50% of native speed of what machine running statically recompiled code from what machine? You need to put some context on that or I'll throw my 10,000% of native speed for my only attempt at static recompilation... Oh that was an Atari ST game recompiled to C and then run on an AMD3500+, yes I was getting FPS > 5,000 :lol:

BTW QEMU translators are generally not slowed down because QEMU supports both system and user mode (at least the ARM front-end is certainly not). The limitation is rather that they target an intermediate language, so some of the things you'd do when going directly from x86 to ARM are lost (such as flags computations).

 

[gilesjuk]

You only need to emulate when the code is not portable or not available. When the code is portable (non processor specific) and available it's better to recompile for the target processor.

Even when there's some x86 machine code you may still be able to rewrite it in C or ARM machine code if you're brave.

 

[fischju2000]

4"] QEMU isn't at the pinnacle of binary translation performance. If you only have to worry about writing a user mode binary translator and don't have to emulate any system mode functionality, hardware, or even memory, then writing a new x86 to ARM dynamic recompiler is not that much work and more effort can be spent on optimizing it. The requirements shouldn't be much different from M-HT's static recompiler, which attains 40-50% native speed on at least one test and contains almost no analytical optimization save for flags. This should give an indication of what you can achieve relative to QEMU's current performance.

40-50% of native speed of what machine running statically recompiled code from what machine? You need to put some context on that or I'll throw my 10,000% of native speed for my only attempt at static recompilation... Oh that was an Atari ST game recompiled to C and then run on an AMD3500+, yes I was getting FPS > 5,000 :lol: [/quote]See this thread: http://forum.openhandhelds.org/viewtopic.php?f=24&t=931

 

[Exophase]

40-50% of native speed of what machine running statically recompiled code from what machine? You need to put some context on that or I'll throw my 10,000% of native speed for my only attempt at static recompilation... Oh that was an Atari ST game recompiled to C and then run on an AMD3500+, yes I was getting FPS > 5,000 :lol:

That's not what people generally mean by "native speed" when they're talking about binary translation or virtualization.

What I meant was that M-HT took a program, compiled it for Linux ARM (let's call this program A), compiled it for DOS x86 (call this B) , used a static binary translation to convert it to Linux ARM (call this C), and benchmarked A vs C. The result was C ran between 40 and 50% of A.

.

Correction, it's because they target a too weak intermediate language and don't do a lot of optimizations to or from it. You can do great things with an intermediate language, although trying to design one that supports a lot of different things like flags of many architectures would eventually drive you insane.

 

[Kyo]

I'm curious about Windows 95/98 myself in Qemu; they should be runnable fine but the requirements of the game are in question. For myself, I want to run:

Why Qemu, though? Anything up to ME can be done in dosbox, which is significantly more efficient than using Qemu from what i've heard