Will We Have Qemu (x86 System Emulation On Arm)?


'Exophase' said:
'Esn' said:
Very interesting post. Forgive me for asking, but does this mean that games from the mid-1990s that required EITHER DOS or Windows 95 could in fact be possible to run at a good speed, as long as the "Windows 95" version is used? Here is one example:

CODE
http://en.wikipedia.org/wiki/Star_Control_3
Depends on many factors, but it's at least possible.

Thank you very much for the reply and the bit of hope.

This thread has reminded me that I really miss discussions like this - developers talking in tech-lingo about new programming ideas for our console and me not understanding most of it but feeling privileged to be given a glimpse into this discussion between experts and feeling the enthusiasm rub off a little. I haven't been seeing a lot of that with the Pandora in the past few months, either because not many people are developing for it or because most of the dev talk goes on in the secret forum. I hope that this changes once the console is actually released. These types of discussions are what this whole community is about, after all, not polls about release dates and wranglings about warranty...
 
Last edited by a moderator:
'Exophase' said:
You can't do register allocation or any real multiple instruction analysis at all. This is a pretty big loss for a load-store arch like ARM. It's pretty naive in general for anyone to think that a "portable" recompiler copying around chunks of C code can come close to a fine tuned one.
Oh, you obviously are talking about the old released qemu, what is currently in dev is vastly different :) Now qemu uses an intermediate representation and generates code,including register allocation. There's also backwards liveness analysis.
You should take a look at qemu svn instead of basing your judgement on a year-old release ;)

QUOTE
5 cycles on what ARM? If it's Cortex-A8 then that's not really that good.

5 cycles on my amd64 for each C-A8 instruction. I did not claim it's very good. But assuming C-A8 has half the IPC of my amd64, and given that on my machine x86 qemu also needs about 5 cycles per x86 instruction, this would mean about 10 cycles / x86 instruction on A8. Assuming 1 instruction is 1 cycle on 486, that'd mean about 60 MHz.

Of course this is all speculation, and I agree with you that a dedicated simulator would faster. But I disagree on dismissing qemu :p
 
Last edited by a moderator:
'Laurent' said:
Oh, you obviously are talking about the old released qemu, what is currently in dev is vastly different :) Now qemu uses an intermediate representation and generates code,including register allocation. There's also backwards liveness analysis.
You should take a look at qemu svn instead of basing your judgement on a year-old release ;)
Ah, is that the case. You can't very well blame me for not knowing about things in code that's not officially released though.

All liveness analysis is backwards, or at least I'd like to see the kind that isn't ;P

I'd love to see some actual translation examples, especially from x86 to ARM instead of the other way around (that's what this thread is about, isn't it?). Can qemu log/disassemble these? Maybe there are published examples?
 
Last edited by a moderator:
'Exophase' said:
Ah, is that the case. You can't very well blame me for not knowing about things in code that's not officially released though.

I certainly don't blame you :D In fact I have spending so much time on qemu recently that I forget the last release is a year old. There should be a new release in the coming weeks.

QUOTE
All liveness analysis is backwards, or at least I'd like to see the kind that isn't ;P

Then just type "forward liveness analysis" on google ;)

QUOTE
I'd love to see some actual translation examples, especially from x86 to ARM instead of the other way around (that's what this thread is about, isn't it?). Can qemu log/disassemble these? Maybe there are published examples?

I alas don't have time to spend on that :( qemu can indeed dump guest + IR + host disassembled code.
 
Last edited by a moderator:
'Laurent' said:
Then just type "forward liveness analysis" on google ;)
10 hits, with about half of them being "straight-forward"? That's a number so small as to be considered background noise. I'll take your word on it though.
 
Last edited by a moderator:
This is interesting...

What about Linux games that are only available in an x86 compatible binary? I played with a DEC alpha once and its NT recompile stuff worked pretty nicely. I wonder if it will ever be possible to...

Boot Neverwinter Nights Linux binary at 1/5 of 500 MHz speed, but using a native OpenGL accelerator! :)
NWN linux
(recommended min specs is 400 MHz K6II with 128 MB ram... I can cope with ultra-low res and 1/5 the framerate...)

Is there an offline optimising binary recompiler available that takes x86 binaries for linux and warps them into arm, then optimises?
 
Last edited by a moderator:
'michield' said:
This is interesting...

What about Linux games that are only available in an x86 compatible binary? I played with a DEC alpha once and its NT recompile stuff worked pretty nicely. I wonder if it will ever be possible to...

Boot Neverwinter Nights Linux binary at 1/5 of 500 MHz speed, but using a native OpenGL accelerator! :)
NWN linux
(recommended min specs is 400 MHz K6II with 128 MB ram... I can cope with ultra-low res and 1/5 the framerate...)

Is there an offline optimising binary recompiler available that takes x86 binaries for linux and warps them into arm, then optimises?

I think NWN would run at like 1fps under x86 emu
 
Last edited by a moderator:
'michield' said:
What about Linux games that are only available in an x86 compatible binary? I played with a DEC alpha once and its NT recompile stuff worked pretty nicely. I wonder if it will ever be possible to...
[...]
Is there an offline optimising binary recompiler available that takes x86 binaries for linux and warps them into arm, then optimises?

To the best of my knowledge that's what DEC emulator was doing to run x86 on Alpha (fx!32). But I don't know of any open source project for such a beast (I don't even know of any such production-quality project).
 
Last edited by a moderator:
'cb88' said:
also the Alpha is a very powerful processor ... server grade versus desktop x86
The Alpha *was* powerful. Most desktop processors made by Intel and AMD now are *much* faster. The fastest Alpha processor reached about 1000 SPECint 2k. For comparison a Core2 @2.93 GHz is >3000 and a Core2 @1.9 is close to 2000.
 
Last edited by a moderator:
Hello, again (hoping this thread isnt too old)...

I ran this with qemu (the Ångström qemuarm target - qemu -M versatile-pb - same kernel as with the new "test Ångström" image). But i created my own filesystem with the Narcissus Ångström image builder - essentially so it had the toolchain. Then i compiled qemu (svn - but not totally recent (about from when i started this thread)) on it (more on all the deps later) on it - with --target-list="i386-softmmu i386-linux-user" (tugged that from memory - not exactly certain that is). Then copied my minimal x86 tux (with Xorg+twm+wine+Stars! on it) to the filesystem and tried to run it. And it (qemu emulating i386 running on qemu-system-arm (that ran on i386 :p)) loaded the BIOS ok- booted grub ok- loaded linux kernel ok- started kernel ok- ran init... and boom:
qemuonarmemulatingx86fa.png
(init segfault)

So it still has something not quite right :( (by this stage i had my hopes high...) . I posted this stating the ~current state of affairs and in hope if anybody can decipher anything useful out of that dump (the arm kernel is 2.6.26-rc4 that comes with the just posted "test ångström on windows" thingy (used it as an easy way to get a hd image and kernel and ready-to use qemu command line) and the x86 kernel is my self compiled 2.6.28.5 - and the host x86 kernel (the only kernel touching real hardware) is a ~recent ArchLinux stock 2.6.28-ARCH).

anyways - here's a list of things to do to get here (in case somebody wants to continue on my work or something - this stuff isn't for the faint of heart (or the ones frightened by loud noices & long division)).
- have linux with qemu (qemu-system-arm)
- get the 7z self extracting (for win) package - run it with wine (or extract with 7z?)
- change the start.bat to start.sh (add #!/bin/sh and remove .exe (of qemu-system-arm) and chmod +x)
- build an image with the Ångström image builder including the toolchain:CODE
http://amethyst.openembedded.net/~koen/narcissus/

(The exact image i used was this: (3 days and it goes bb) CODE
http://amethyst.openembedded.net/~koen/narcissus/deploy/qemuarm/7b70c8/random-7289058d-image-qemuarm.tar.bz2

(58.34MB)
- create an empty 512M file (i renamed hdd.img and put this in its place) (dd) create ext3fs on it (mke2fs -j) loop mount it (root rights required) (mount -o loop hdd.img /mount/point)
- extracted the .tar.bz2 to the image mounted
- include all this stuff (i had to reboot the system many times for this - boot once to create the user if you like):
SDL-1.2.13 (.tar.something originally), xextproto-7.0.3.tar.bz2,
libX11-1.1.5.tar.bz2,qemu-svn-src
(eg. check out the qemu svn on the host and dump it to the hd image),xproto-7.0.13.tar.bz2
libXext-1.0.4.tar.bz2,libXrandr-1.2.3.tar.bz2,zlib-1.2.3.tar.gz
libXt-1.0.5.tar.bz2
- run the start.sh and wait a moment (even on an Core 2 Duo P8400...)
- ok so you need zlib and X11 headers (i re-installed zlib before i understood the next thing)
- so re-configure&install zlib plus cp zlib.h zconf.h /usr/include
(or just copy the .h and go to /usr/lib to create link (in /usr/lib) libz.so to libz.so.1 (or the like))
[This stuff worked for me but really i think isnt recommended (but tell me when you find the X11 headers in the Ångström repos - the xproto package (that said headers in the description) was for example .. empty .. duh(686 bytes ipk no data only control):]
- unpack all the X-something packages - find out where the headers are in the package (include dir or at root usually) and rename *.h.in to .h (found two) (this might not be good advice - one should really run auto*(something) to create them) and just copy the headers to the place where they should be - i checked where they were on my host system (/usr/include/X11{/extensions})..
- go and create links libX*.so -> libX*.so.? (for all libX's included above (in /usr/lib)) (otherwise ld wont find them) - this took a while to figure out (ld wont find libX11.so.6 if you say "gcc -lX11 ...", it will find libX11.so)
- compile&install SDL (i did just with ./configure --prefix=/usr (watch it to make sure X is found - boring job) then make and then to root rights and make install)
- configure qemu with --prefix=/usr --install-target="i386-softmmu i386-linux-user" (i386-softmmu only should work too if you want system emulation only) (i passed --no-kqemu too but i dont think that had any effect...)
- compile qemu (make) (this will take a while) (even the configure takes a while though)
- install qemu (make install as root)
.. qet some x86 hd image to test (small - mine was ~50M qcow (compressed)) and run qemu :p
(just to show the bios you can say qemu -m 32 /dev/null (0MB hd then...))

Uh... report finished :p
 
Last edited by a moderator:
you are doing it all just to test if it'll run or not?
isn't it better to just cut the problems in half and have it tested on the pandora directly? (either wait or have some nice person with a devboard to give it a try)
 
Last edited by a moderator:
'.Gogeta§§J4BR.' said:
you are doing it all just to test if it'll run or not?
isn't it better to just cut the problems in half and have it tested on the pandora directly? (either wait or have some nice person with a devboard to give it a try)
Well i sorta had all day free to do stuff and just did this mostly in the background :p. I'm just really experimenting with this stuff for fun.. (I might be a bit weird to consider seeing whether some "odd system"* compiles and runs some other (tasking) software fun, but :p)

<OT>:
*(I have a really totally customized linux on my AST 486 25Mhz laptop that i really novadays never use :p (I mean, the distro doesnt have a name - all i can say that its "uClibc/Linux" (with the initial image made by buildroot))
 
Last edited by a moderator:
Many people react negative at Qemu for pandora, often because they assume it's some frantic that haven't realised that he can't play his favourite x86-games without recompilation. But this is for me and many others (I believe) not the case. The ability to run small applications compiled for x86 (CPU non-heavy) would be extremely useful. I can see a number of cases were I don't have the source code for a program, but I still do want to run it. Do anyone here agree with me?
 
Last edited by a moderator:
I'm sure there might be something qemu would be useful for, but I can't really think what it would be.

The only closed-source I use is like, drivers and video games.
And with emulation, you're pretty limited in what you can run. I suppose you could use it with a small Linux distro to run something like a web server that hasn't been ported yet, but I'm not sure what kind of applications will run on a slow emulated x86 that somebody won't already be porting.
 
Last edited by a moderator:
'GuSec' said:
Many people react negative at Qemu for pandora, often because they assume it's some frantic that haven't realised that he can't play his favourite x86-games without recompilation. But this is for me and many others (I believe) not the case. The ability to run small applications compiled for x86 (CPU non-heavy) would be extremely useful. I can see a number of cases were I don't have the source code for a program, but I still do want to run it. Do anyone here agree with me?
I agree :p
For me it's things like emulating a "real" DOS machine (retro things) (There's dosbox - but it's like "only for games"), W3.1 based things and maybe MINIX2 (the 16-bit version) (I fell in love with it when i put it into one old 80286 - it's amazing that the 80286 at 16mhz could recompile the minix kernel in some 20mins or so (i dont remember exactly)) . I totally understand that it wont be able to run anything CPU-heavy or 3D-accelerated, and running those new/newish 3D games is not the point.

Of course the another point of this is if the user space emulation would work properly with wine it could propably emulate many small useful apps (things you dont have the source for and the developer is long gone).
 
Last edited by a moderator:
Back
Top