Wine mittels Qemu auf der Pandora

[Anonymous]

Es gäbe eine Möglichkeit, sehr günstig den x86 zu "emulieren":
man schreibt einfach die Bytes in doppelter oder dreifacher Breite in den RAM, damit genug platz ist für die längeren ARM-Befehle und füllt anschließend für jeden x86-Command mehrere ARM-Commands, um das zu emulieren. Die entstandenen Lücken füllt man dann mit NOPs.

Das habe ich nicht verstanden, bitte ausführlicher erklären! Bitte auch berücksichtigen, dass sich Offsets für Daten und Sprünge verändern und dass x86-Code Befehle unterschiedlicher Länge hat, wobei ohne Kenntnis der "Vorgeschichte" nicht immer klar entscheidbar ist, wo ein Befehl anfängt.

 

[carli]

Bitte auch berücksichtigen, dass sich Offsets für Daten und Sprünge verändern und dass x86-Code Befehle unterschiedlicher Länge hat

genau deshalb hab ich ja die "Lücken" erklärt:

Man verbreitert einfach den Speicher ein bisschen und füllt den doch nicht genutzten Platz mit NOPs.

 

[hede]

Re: Command & Conquer 1 Tiberium Konflikt DosBox

<r>350 MHz Pentium-III hin oder her!? So pauschal kann man das gar nicht sagen. Was Aufgaben der ALU angeht (Integer, Load, Store) dürfte der ARM gar noch besser dar stehen. Sobald man mit Fließkommazahlen rechnet weit schlechter. Wenn ein P3-350 per Emulator nicht auf P1-90-Speed kommen sollte, heißt das also noch gar nichts. Weder in die eine, noch die andere Richtung.<br/>
Ich warte erst einmal ab. Dass man wirklich am Ende was schnelleres als einen Mittelklasse-486er hin bekommt, das bezweifle ich nämlich auch irgendwie. <E>;-)</E><br/>
<br/>
Qemu plus WinE hätte schon was. Es vielen die Lizenzprobleme weg. Denn das echte MS Windows 3.1 dürfte ja schon unter DosBox laufen, so wie schon auf dem N900 dämonstriert<sic>.<br/>
(edit: oder WinNT oder Win95, was für Spiele interessanter sein dürfte)</r>

 

[Gurumeditation]

Naja nur das man kein Windows direkt brauch. Wine reicht ja aus und das wäre ja schon eine hammer sache =)

 

[Anonymous]

Bitte auch berücksichtigen, dass sich Offsets für Daten und Sprünge verändern und dass x86-Code Befehle unterschiedlicher Länge hat

genau deshalb hab ich ja die "Lücken" erklärt:

Man verbreitert einfach den Speicher ein bisschen und füllt den doch nicht genutzten Platz mit NOPs.

Ja, und genau das habe ich nicht verstanden. Wie rechnest Du dann z.B. einen zeigerindirekten Speicherzugriff mit Offset auf Operanden um? Wie erkennst Du Adressarithmetik (also die Berechnung einer Speicheradresse aus irgendwelchen Daten, die Du dann frühzeitig als Adressdaten erkennen müsstest, was Du aber nicht wissen kannst).

 

[ashcloud]

Für wine auf der Pandora müsste ja eigendlich nur binfmt_misc im Kernel vorhanden sein, was ja eigendlich nicht so ein Problem sein dürfte. Wenn das nicht schon reincompiliert wurde, sollte das unbedingt geändert werden. Qemu kann man sich z.B. von Debian klauen: http://packages.debian.org/de/sid/armel/qemu-user-static/download. Das ist statisch gelinkt, also von keinem anderen Paket abhängig. Dann kann man sich z.B. ein Debian Dateisystem mit installiertem wine erstellen. Die qemu-binary für i386 landet dann in /path-to/debian-root/usr/bin.
Dann mit chroot hineinwechseln, nachdem man

for i in dev sys proc dev/pts dev/shm
do
mount --bind /$i /path-to/debian-root/$i
done

gemacht hat.

Leider hab ich noch lange keine Pandora, sonst hätte ich das schon längst ausprobiert.
Andersherum, von x86-64 -> arm funktioniert es wunderbar. Warum sollte es nicht auch so funktionieren?
Man sollte sich allerdings keine Performancewunder erhoffen...

 

[carli]

Bitte auch berücksichtigen, dass sich Offsets für Daten und Sprünge verändern und dass x86-Code Befehle unterschiedlicher Länge hat

genau deshalb hab ich ja die "Lücken" erklärt:

Man verbreitert einfach den Speicher ein bisschen und füllt den doch nicht genutzten Platz mit NOPs.

Ja, und genau das habe ich nicht verstanden. Wie rechnest Du dann z.B. einen zeigerindirekten Speicherzugriff mit Offset auf Operanden um? Wie erkennst Du Adressarithmetik (also die Berechnung einer Speicheradresse aus irgendwelchen Daten, die Du dann frühzeitig als Adressdaten erkennen müsstest, was Du aber nicht wissen kannst).

Aber das hab ich doch gerade zum zweiten Mal erklärt.

Jetzt zum dritten mal:
Zeiger, bei der Dereferenzierung (beim Zugriff auf die Speicherstelle) wird die Adresse mit einem konstanten Faktor multipliziert. (sozusagen wird der Speicher gespreizt) Außerdem werden Schreibzugriffe in ein Codesegment gefiltert und die geschriebenen Daten werden in ARM-Opcodes übersetzt.

 

[liko]

Cool mach mal.