Ein x86 Prozessor ist in der Lage eine ganze Menge teilweise sehr komplexer Operationen in nur einem einzigen Schritt auszuführen. Das war in der Vergangenheit notwendig, da man immer mehr Rechenoperationen in noch weniger Zeit unterbringen wollte. Und da man die Taktfrequenz aus verschiedenen Gründen nicht einfach immer weiter hinauf schieben kann, hat man dann dafür gesorgt, dass man die gleichen Operationen in weniger Takten ausführen kann. Um diese Komplexität zu erreichen braucht man eine ungeheure Anzahl von Transistoren zusätzlich, die den komplexen Maschinencode interpretieren und dann richtig verarbeiten können.
Beim ARM ist es anders herum konzipiert: Man wählt bewusst einen reduzierten Befehlssatz, der nur sehr allgemeine Befehle enthält. Damit kann man prinzipiell immer sein Ziel erhalten, aber manchmal nur auf Umwegen, d.h. mehrere Schritte für eine bestimmte Operation = mehr Zeit. Was man dabei aber gewinnt, ist dass man sich eine wahnsinnig große Menge an Logik sparen kann, da die Interpretation des Maschinencodes mit einer deutlich geringeren Auswahl an Befehlen auch deutlich einfacher ist.
Die unmittelbaren Vorteil für uns alle:
- wesentlich weniger Transistoren = deutlich günstiger (ein durchschnittlicher ARM Prozessor kostet nur wenige Euros)
- wesentlich weniger Transistoren = wesentlich weniger Energieverbrauch / Wärmeentwicklung
wine macht folgendes: Rufe das Programm UcxLog.exe (Windows) auf und schau was es will. Für die gesamte Kommunikation mit dem Rechner selbst (der ja nun einmal keinen Windows, sondern einen Linux-Systemkern hat) dient es danach als Übersetzungsprogramm. Es generiert wieder gültigen x86-Code, der unter Linux läuft (darf auf den Arbeitsspeicher und das Internet zugreifen, etc.). Und das obwohl das Programm ursprünglich gar nicht für diese Umgebung. Sehr gute Leistung.
Aber jetzt kommt das aber: wine kann eben auch nicht mehr als gültigen x86-Code erzeugen. Doch damit kann der Prozessor vom Raspberry nichts anfangen -> UcxLog startet nicht.
Was du mit dem Übersetzen aus den Quellen erreicht hast, ist dass Wine selbst auf dem Raspberry läuft. Dennoch generiert es natürlich Code für x86, der dann nicht weiter verarbeitet werden kann. Die Entwicklung und das Festlegen welcher Code wann wo wie ausgeführt werden muss, war eine absolute Meisterarbeit und wird sich auf keinen Fall (in kurzer Zeit) auf eine gänzlich andere Architektur übertragen lassen. Im Prinzip ist es ein völlig neues Projekt, wobei es noch komplizierter wäre (die Befehle die man übersetzten will gibt es ja meistens gar nicht 1:1 beim ARM). Das Problem ist also ganz fundamentaler Natur.
Aber es gibt eine Lösung: Man lässt wine wie gehabt gültigen x86 Code erzeugen. Hier kommt jetzt qemu ins Spiel. Eigentlich dazu gedacht andere Architekturen zu simulieren (z.B. für die Entwicklung völlig neuer Chips), kann es mittlerweile auch den anderen Weg gehen: x86 Code auf ARM übersetzen. Dieser (und nur dieser) Code kann dann auf dem Prozessor ausgeführt werden und UcxLog startet. Aber man muss ich klar sein, dass man einen Trick auf einen Trick aufsetzt um es irgendwie ans Laufen zu bekommen. Es ist halt nicht vorgesehen Windowsprogramme auf dem Raspberry zu betreiben. Selbst für Microsoft waren die Hürden scheinbar zu groß, denn selbst unter dem aktuellen Windows 8.1 für Tablets lassen sich keine x86 Programme, sondern nur von vornherein für ARM kompilierte Programme, nutzen. Wir versuchen etwas wo der Hersteller selbst keine Unterstützung für gibt. Un ich bin mir ziemlich sicher, dass sie es tun würden, wenn sie es (mit vernünftigen Geschwindigkeiten) könnten!
In diesem Sinne besitzt Linux ein einzigartige herausragende Position, denn da alle Programme als OpenSource vorliegen, wurde schon fast alles auch für ARM kompiliert und kann einfach genutzt werden. Da UcxLog aber nicht als OpenSource vorliegt, bekommt man es nicht auf dem einfachen Weg auf das Raspberry.
Ich hoffe, dass nun der Hintergrund und die Problematik klarer geworden ist. Für weitere Testvorschläge und Fragen bin ich natürlich offen
73 Dominik
).