ARM (Archimedes Risc Machine) ist ein extrem schneller Prozessor, eben weil er nur eine Handvoll Instruktionionen hat, dafür mit vielen sinnvollen Adressierungsarten, Bedingter Ausführung und anderen "Leckereien" die andere CPUs nicht können. Man muss es nur nutzen und das wird wohl kaum getan. Das schöne bei ARM ist, daß alle Instruktionen in hardware realisiert sind und nur einen Takt dauern, nicht wie bei cics wo ein Befehl viele Befehle dauern.
Wie effizient Bedingte Ausführungen sind sieht man Eindrucksvoll auf Folie 25 http://www.simplemachines.it/doc/arm_inst.pdf
Zum Vergleich: Der Arcon Archimedes (mit Risc OS) konnte damals (ARM2, 8 MHZ) einen DOS-Computer emulieren (damals 80286, 80386), im vergleich zu einem echtem PC mit 8 MHZ war der emulierte sogar schneller.
Auf Nintendo DS gibt es einen Homebew-Macemulator, dieser emuliert den Ur-Mac in etwa in Originalgeschwindigkeit (68000 CPU, ca. 8 MHZ)
Auf Nokia N97 kann man DOSEMU installieren und dann Windows 3.1 und sogar Windows 95 ausführen (wobei dies ein wenig träge ist).
Warum man bei den Geräten Gigaherz und Multiprozessor braucht, ist mir schleierhaft, warum es keine Handies mit RISC OS gibt ist mir auch schleierhaft.
Das dumme für Android ist, daß obwohl der ARM 30 Register hat (von denen man 13 nutzen kann) der Java Bytecode eigentlich gar keine Register verwendet sondern nur den Stack.
Ein Regisgter ist im Prozessor eingebaut und daher sehr schnell. Der Stack liegt im Hauptspeicher und dieser ist im Vergleich zum Prozessor sehr langsam, man muss die Daten vom Stack erst in ein Register laden um es verwenden zu können (und andersrum).
Der Bytecode wird zwar in Dalvik umkompiliert aber das ist auch nur eine virtuelle Maschine und es wird wohl nicht optimiert. Auf den Geräten muss dann jede Dalivk-Instruktion interpretiert werden. Insgesamt sehr uneffizient. Warum es für Android keinen Compiler gibt, der optimierten Native Code baut, ist unverständlich, es würde viele Probleme lösen. Außerdem hat Java noch das Problem des garbage-Collection (Speicher wird nicht freigegeben sondern als Frei markiert und irgendwann werden diese freien Blöcke zusammengefaßt und zusammengeaschoben um den Platz entgültig wiederzuverwenden). Deswegen dieses Fragmentierugnsproblem.
Systeme, welche "native" arbeiten, also der Compiler direkt ARM Code erzeugt, sind daher im Vorteil (Symbian, Meego, Tizen, Bada, iOS,...). Bei Windows geht es wohl über die CIL (Common language, ein stack basierter Bytecode) und wird entweder auf dem System (Just in Time) oder zur Entwicklungszeit in native code übersetzt. Inwieweit diese Übersetzung optimiert, ist mir unbekannt.
Es wäre technisch kein Problem unter jedem OS (Symbian, Meego, Bada, iOS, Windows) einen Daliv-Interpreter und die nötigen Bibliotheken zu implementieren und dann alle Android-Progrmme ausführbar zu machen --- würde Symbian interessanter machen, so einm Projekt :-) ----------- [Keine Empfehlung, bitte selbst denken]
God bless the Blessing |