Thema: Auf Android entwickeln

[LittleFox]

Hi,

da ich so gerne den OT Bereich vollspamme, wieder mal ein neues Thema

Ich überlege momentan meinen Laptop zu verkaufen (NIE wieder Thinkpad Edge!) und mir etwas neues zu holen.
Da mir vorallem eine lange Akkulaufzeit wichtig ist, bin ich ziemlich schnell auf Tablet PCs gekommen.
Habe jetzt einen Favoriten gefunden der allerdings Android als Betriebssystem verwendet. Bei den Tablet PCs ist es ja leider so das sich andere Betriebssysteme nur schwer installieren lassen.

Meine Frage ist nun, ob man auf Android gut programmieren kann. Gibt es Entwicklungsumgebungen, gcc, etc.? Mir wäre auch noch wichtig x86 Code erzeugen zu können. Qemu wäre auch nicht schlecht
Oder könnt ihr mir ein Tablet PC mit ähnlicher Ausstattung und langer Akkulaufzeit auf x86 Basis empfehlen? Tastatur wie bei deisem wäre schon nicht schlecht.

Danke für eure Hilfe

Grüße,
LittleFox

[Svenska]

Vergiss es. Android ist meiner Meinung nach zum produktiven Arbeiten total ungeeignet. Der Kram ist zum Konsumieren gebaut, mit dem Überallinternet, wenig selbst machen (und wenn, dann nur kurze Twittermeldungen) und viel Überwachung inklusive.

Aktiv drauf entwickeln ist damit nahezu unmöglich. Android selbst besteht dann in der Regel aus einem zugepatchten Linux-Kernel und einer total zugenagelten Umgebung (d.h. Linux ohne Rootrechte und eine komplett unlinuxartige GUI). Vielleicht geht ein bisschen Java plus Dalvik, aber das ist Anwendungsprogrammierung, ins Linux kommst du damit nicht.

Was du willst, ist ein Betriebssystem, keine Konsumentenverarsche. (Tut mir Leid für die harten Worte.) Also entweder ein x86-PC/Netbook oder ein Netbook mit ARM-CPU und zugänglichem Bootloader. Ob der allerdings ohne Löten (serielle Schnittstelle) ebenfalls zugänglich ist, ist dann noch die zweite Frage. Wenn du ohnehin für x86 entwickeln möchtest, rate ich von ARM ab, ansonsten ist das eine echt nette Architektur mit in der Regel guter Dokumentation.

Von Android (oder auch iOS) rate ich definitiv ab, wenn man damit was Produktives tun möchte.

Gruß,
Svenska

[LittleFox]

Hi,

danke füt deine Antwort.
Ich hatte gehofft das Android noch genug Linux ist damit e sollche Programme gibt.

Leider habe ich kein ARM-Tablet ohne OS gefunden, und auf x86 hab ich keine Lust mehr Akkulaufzeit ist nunmal viel zu kurz ...

Dann werde ich also weiter suchen müssen, oder kannst du eins empfehlen?

Grüße,
LittleFox

[Svenska]

Hallo,

ich habe ein Archos 70. Das besitzt eine SDE (Software Developer Edition, ein Ångström Linux), weswegen ich mir das hab schenken lassen, bin aber ziemlich enttäuscht. Das Android 2.2 auf dem Gerät ist komplett zugenagelt (squashfs mit signierter MD5-Prüfsumme, sonst bootet der Bootloader das nicht) und die SDE unterstützt kein WLAN, kein 3D und ist mehr oder weniger nutzlos. Theoretisch kann man einen eigenen Kernel bauen und es gibt ein halbtotes Projekt für Android 2.3, aber groß Hoffnung habe ich da nicht mehr. Und Archos ist der einzige mir bekannte größere Hersteller, der sowas anbietet.

Was du suchst, suche ich auch schon länger. Sowas gibt es aber nicht, erst recht nicht zu günstigen Preisen. Vielleicht kann man irgendwelche billigen China-/Indien-ARM-Netbooks aufbohren, aber ob das den Aufwand lohnt, ist fraglich. Es gibt halt keine Plattform, neben dem mitgeliefertem OS keinen Support und keine Plattform-Dokumentation. Bei x86 gibt es eine spezifizierte/dokumentierte Plattform und die Möglichkeit, verschiedene OSs zu booten.

Tablets sind für Development ungeeignet, weil Bildschirmtastaturen einfach hässlich sind.

Gruß,
Svenska

[LittleFox]

hi,

das es für tablets keine einheitliche platform gibt habe ich auch schon festgestellt. Gibt es dafür eigentlich irgendeinen grund oder hatten die hersteller bis jetzt nur keine lust?
Das man auf einer bildschirmtastatur nicht gut programmieren kann, ist mir klar, deswegen hatte ich ein tablet mit tastatur ausgesucht (siehe link)
wie realistisch ist es eine art "offene plattform" zu entwickeln? Bzw. Diese so zu verbreiten das sie auch verwendet wird?

Grüße, LittleFox - der heute keine lust auf groß- und kleinschreibung hat

[Svenska]

Hallo,

das hängt damit zusammen, dass IBM den PC-Standard offen entwickelt hat und jeder den nutzen konnte. Für x86 gibt es nur zwei Plattformen: PC (BIOS) und EFI. Bei ARM hat jede CPU Unterschiede (z.B. die Adressen, wo RAM liegt, welche Schnittstellen existieren und wie man deren Adressen erfragt usw) und dann hat jeder Board-Designer wieder die Möglichkeit, externe Perioherie verschieden anzuschließen.

Bei PCI-Geräten fragt man nach, was wo ist. Wenn der Board-Designer die Kamera aber an GPIOs 12-22 verbaut hat, muss man das wissen. Ein anderes Board mit gleicher CPU könnte da das Netzteil für den Stromsparmodus mit steuern, deswegen ist Probing schlecht.

Offene Plattformen gibt es genug - Evaluationsboards von Pollin bis Samsung, Texas Instruments bis STMicroelectronics. Das sind aber immer nur Boards ohne Gehäuse. Und Standards gibt es da nur im großkommerziellen Bereich, nix für Endkunden. Leider.

Gruß,
Svenska

[Sannaj]

Das ist halt der Große Nachteil von ARM, die Architektur wurde bei ihrer Verbreitung ziemlich in den Mikrokontrollerbereich abgedrängt, wo sie sich nur extrem unzureichend standardisiert wurde. Auch heute konnte sich die Architektur nicht vernünftig von ihrem  Bei x86, kannst du sicher sein, das sich alle Sachen ab der Plattform auf der sie eingeführt wurden auch immer genauso verhalten.
Bei ARM ist das nicht so. Deshalb wird im Wiki auch nicht beschrieben, wie man den Bildschirm mit Zeichen bestückt, sondern nur die "Debug"-Ausgabe über die serielle Schnittstelle an den Emulator. Auch das dort beschriebene Paging ist mit leichter Vorsicht zu genießen. Aus diesem Grund denke ich dass ARM nicht keine echte Chance bei Systemunabhängien Plattformen haben wird, es sei denn es ändert sich in naher Zukunft irgendetwas.

[erik.vikinger]

Hallo,

Auch das dort beschriebene Paging ist mit leichter Vorsicht zu genießen.

Das Paging ist eine interne Angelegenheit der ARM-CPU und die einzelnen Kunden von ARM (die dann die CPU zusammen mit der Peripherie auf ein Stück Silizium packen) ändern an der CPU selber (normalerweise) nichts. Für den Linux-Kernel ist meines Wissens nach der größte Aufwand beim Portieren das Erstellen eines BSP, an der eigentlichen CPU-Unterstützung wird da nicht viel gedreht. Auch sind Dinge wie die JTAG-Schnittstelle, der IRQ-Controller oder auch der CPU-lokale Timer immer gleich, zumindest innerhalb einer ARM-CPU-Generation, z.B. von ARMv5 nach ARMv6 sind da schon einige Unterschiede.
Das wirkliche Problem von ARM ist das die gesamte Peripherie, eben alles was echten Kontakt zur Außenwelt hat, auf jeder ARM-Realisierung anders ist. Wenn man hier wirklich was effektiv ändern wollte dann sollte man IMHO alles auf PCI umstellen und in der CPU einen standardisierten Zugriff auf den PCI-Config-Space einbauen. Das Problem ist dass das bei kleinen Micro-Controllern sicher gleich mal die Anzahl der benötigten Transistoren verdoppeln würde (einfach nur weil 30 kleine Peripherie-Geräte, die oft nur ne Hand voll Register haben, plötzlich einen fetten Config-Space bräuchten und weil Routing mit flexiblen Adressen auch deutlich aufwendiger ist). Das hat aber die Firma ARM selber kaum in der Hand und so lange die vielen Hersteller gar kein Interesse daran haben das ihre Produkte einfach so gegen das Produkt eines anderen Hersteller ausgetauscht werden können wird sich das auch nicht ändern. Die Hersteller setzen ja gerade deswegen auf ARM weil sie eben nicht damit rechnen müssen das der Endkunde jedes Teil nach belieben austauschen kann. Dabei täte ja echte Konkurrenz entstehen und die Hersteller müssten sich plötzlich bemühen mit Qualität usw. zu punkten und das kann doch keiner ernsthaft wollen oder?


An einem offenen Tablet-PC mit ARM-Innenleben bin ich ja auch interessiert aber sowas hab ich noch nicht gesehen und ich rechne auch nicht damit sowas mal zu bekommen.


Grüße
Erik

[Svenska]

Bei ARM ist das nicht so. Deshalb wird im Wiki auch nicht beschrieben, wie man den Bildschirm mit Zeichen bestückt, sondern nur die "Debug"-Ausgabe über die serielle Schnittstelle an den Emulator.

Richtig, denn beim Bildschirm handelt es sich um Peripherie. Die meisten ARM-Systeme haben keinen Bildschirm, also ist in der Plattform auch keiner vorgesehen. Beim PC ist das anders, der hat immer eine CGA- oder MDA-kompatible Grafikkarte (ob da ein Bildschirm dranhängt oder nicht, ist eine andere Frage; dass das so ist, erkennt man daran, dass manche BIOSse ohne angeschlossenen Bildschirm nichtmal booten).

Auch das dort beschriebene Paging ist mit leichter Vorsicht zu genießen. Aus diesem Grund denke ich dass ARM nicht keine echte Chance bei Systemunabhängien Plattformen haben wird, es sei denn es ändert sich in naher Zukunft irgendetwas.

Das Paging ist für jede ARM-Architekturversion gleich, bei x86 ist sie immerhin abwärtskompatibel. Ich denke, dass sich für gewisse Geräteklassen quasi-Standards herausbilden werden.

Die Architektur ist zu flexibel einsetzbar, um sie in ein einziges Schema pressen zu können.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Das Paging ist für jede ARM-Architekturversion gleich, bei x86 ist sie immerhin abwärtskompatibel.

Klar kann man es durchaus als herausragende Leistung von Intel betrachten das selbst auf deren aktuellsten Sandy-Bridge-CPUs noch ein 30 Jahre altes DOS mit Windows 3.0 im 286-PM läuft (denke ich mal, praktisch ausprobiert hab ich das noch nicht) aber wird das wirklich von der Mehrheit der Anwender benötigt? Wenn man von einer aktuellen CPU anständig Leistung haben will ist man auch gezwungen deren neuesten Features zu unterstützen. Wenn ich den selben C-Code für das 16Bit Windows 3.0 kompiliere wird er auf der selben CPU sicher deutlich weniger Leistung bringen als wenn er für ein aktuelles 64Bit Windows 7 kompiliert wird. Abwärtskompatibilität ist zwar nett aber nur bis zu einem gewissen Grad wirklich nützlich. Klar würde das 16 Bit Programm auf einer aktuellen CPU immer noch schneller laufen als auf einem originalem 286 (selbst die 286-Nachbauten für die Embedded-Welt haben wimre nie mehr als 100 MHz erbracht) aber trotzdem wäre das Verschwendung von Transistoren, ein neuer Compilerlauf dürfte da schlagartig mindestens 500% mehr bringen. Ich denke die Entscheidung von ARM das innerhalb einer Architektur-Familie die wichtigen Dinge immer identisch sind ist sehr wichtig aber der Schritt zu einer neuen Familie darf IMHO gerne auch mit ein paar Altlasten aufräumen. Wenn durch diesen Schritt sogar die Kompatibilität bei normalen User-Mode-Applikationen entfällt ist das zwar ärgerlich aber ich bin der Meinung das hier die OS-Hersteller in der Pflicht wären dann eben passend zu emulieren, wenn diese Emulation (so wie bei QEMU) auch immer den Code neu auf die Host-CPU anpasst könnte das Programm damit eventuell sogar mehr Performance erreichen als wenn die CPU versucht die alten Befehle irgendwie auszuführen. Wenn dieses Anpassen des Code auf die Host-CPU offline passiert und passend auf der HDD gecached wird würde darunter nicht mal die Startzeit der Programme leiden, das ist ja im Endeffekt auch die Richtung die Microsoft mit .NET anstrebt (nur das dort das Programm noch gar nicht fertig compiliert zum Kunden kommt sondern beim Anwender immer optimal für seine tatsächlich vorhandene CPU umgesetzt wird).
Ich bin der Meinung das Abwärtskompatibilität deutlich überschätzt wird.

Die Architektur ist zu flexibel einsetzbar, um sie in ein einziges Schema pressen zu können.

Ja, das kann ich vorbehaltlos so unterschreiben.


Grüße
Erik

[Sannaj]

Naja, so teuer ist die Abwärtskompatiblität dann doch nicht. Wenn man sich die Effekte mal anschaut fällt einen auf, das die Unterschiede gar nicht so groß sind.
Für den 16 Bit PM braucht man nur eine Flag und ein Xor Gatter. Bei Opcode 0x66 wird die Flag gesetzt. Bei jeder Operation wird dann  mit dieser Flag und der is32bitCode Flag im versteckten Teil von CS ein exclusives Oder durchgeführt. Kommt dann 1 raus, braucht man eine 32 Bit Operation.
Auch für den Real Mode, braucht man blos eine bisschen andere Ladevorrichtung für den versteckten Teil der Segmentregister und einen anderen internen Interupthandler.

Aber zurück zum Thema. Ich kritisieren an ARM auch gar nicht die mangelnde Abwärtskompatiblität. (ARM ist nämlich größtenteils schon abwärtskompatibel.), sondern einfach, das es keine verlässliche Plattform gibt. Paging war jetzt vielleicht ein bisschen unglückliches Beispiel, schließlich steht x86 in der Hinsicht auch nicht besser dar. Sondern ehr die Tatsache, das das, was sich um die CPU befindet nur mangelhaft standardisiert ist. Natürlich brauche ich in einem sprechenen Teddybären keine Bildschirmfunktionalität (und auch kein Paging), aber es wäre doch schön, wenn man bei allen Geräten, die einen Bildschirm haben, diesen auch gleich ansprechen können, zumindest wenn man nur ne primitive Fehlerausgabe haben will.

Durch geeignete Betriebssystem kann das ganze natürlich ein wenig standardisiert werden.

[Svenska]

Ich bin der Meinung das Abwärtskompatibilität deutlich überschätzt wird.

Sehe ich persönlich anders. Emulation funktioniert nur, wenn ein enormer Performance-Unterschied zwischen der emulierten und der emulierenden Architektur liegen. Wenn ein Core i7 nicht zu einem Core2  kompatibel ist, wird keine Emulation schnell genug sein, um die Inkompatiblität zu rechtfertigen. Ein 386er kann einen 286er nicht schnell & sauber genug emulieren, das können die meisten Emulatoren ja noch nichtmal heute!

Gruß,
Svenska

[erik.vikinger]

Hallo,

Naja, so teuer ist die Abwärtskompatiblität dann doch nicht. Wenn man sich die Effekte mal anschaut fällt einen auf ....

Auf die Gefahr hin das man mir gleich Unhöflichkeit vorwerfen wird aber das ist eine recht naive Betrachtung, in Wirklichkeit ist das schon ein wenig komplexer. AMD hat damals bei den ersten 64Bit-Opterons was von 5% mehr Transistoren für den 64Bit-Modus erzählt und 5% sind bei einem Chip der schon einige Millionen Transistoren hat ne ganze Menge und dabei darf man nicht vergessen das ein Großteil der Transistoren für Cache usw. drauf gehen und da dürften die Änderungen eher marginal gewesen sein so das ich persönlich vermute wenn man nur den puren CPU-Kern betrachtet kommen da eher 15 bis 20% Zuwachs bei raus.

Sondern ehr die Tatsache, das das, was sich um die CPU befindet nur mangelhaft standardisiert ist.

Da hast Du auf jeden Fall recht aber dafür sind die Einsatzgebiete von ARM einfach zu extrem unterschiedlich als das man da auch nur den Hauch einer Chance für einen minimalen gemeinsamen Nenner findet.

aber es wäre doch schön, wenn man bei allen Geräten, die einen Bildschirm haben, diesen auch gleich ansprechen können

Dafür sind leider die Bildschirme viel zu unterschiedlich. Es gibt ja nicht nur graphikfähige LCDs sondern auch alpha-numerische Displays (die oft nur einen begrenzten Zeichenvorrat haben zu dem auch nicht immer lateinische Buchstaben gehören).

zumindest wenn man nur ne primitive Fehlerausgabe haben will

Dafür gibt es die Debug-Konsole über JTAG und die ist innerhalb der CPU und damit standardisiert. Dieser JTAG-Trace-Mechanismus ist wimre sogar bei den ganz kleinen ARM-Micro-Controllern (fast) immer mit dabei. Das Problem ist eher das Du bei den typischen Consumer-Produkten nicht mehr ans JTAG ran kommst.

Durch geeignete Betriebssystem kann das ganze natürlich ein wenig standardisiert werden.

Ja, deswegen haben ganz früher mal schlaue Leute das Konzept der Geräte-Abstraktion mit Hilfe von Treibern erfunden und ich persönlich finde dieses Konzept echt gut (schließlich funktioniert es ja auch ganz prima). Diese Aufgabe gehört natürlich in den Zuständigkeitsbereich des OS aber dieses hat das Problem das es nicht ahnen kann welche Treiber den auf dem aktuellen System tatsächlich benötigt werden. Wenn es einen guten Boot-Loader gibt der den Speicher einrichtet und dem OS-Kernel alle Geräte sauber auflistet dann müsste damit ein generisches OS schon prima arbeiten können (es würde dann eine OS-Version pro ARM-Architektur-Familie reichen) aber selbst das gibt es ja nicht auf ARM. Microsoft will doch das Windows 8 nur auf den ARM-Systemen läuft die UEFI haben und damit wäre ja dann endlich genau das vorhanden. Das UEFI für diesen Zweck eher suboptimal und vor allem viel zu groß ist lassen wir jetzt mal außen vor aber von der Theorie her ist das eine gute Lösung.

Emulation funktioniert nur, wenn ein enormer Performance-Unterschied zwischen der emulierten und der emulierenden Architektur liegen.

Dann kennst Du keine guten Emulatoren. Das Zauberwort heißt Code-Morphing. Das hat Transmeta ziemlich gut gekonnt (und das sogar ohne dass das OS das überhaupt bemerkt hat, nur die echte Host-CPU war nicht so wirklich der Bringer), auch Microsoft hat das unter Windows NT 4 mit dem damaligen FX! in ziemlich guter Performance geschafft (die meisten Programme liefen auf der Alpha-CPU sogar schneller als auf einem x86, vielleicht nicht ganz so schnell wie wenn sie nativ compiliert worden wären aber das Ergebnis war durchaus ansehnlich), Apple hat es mit Rosetta wohl ziemlich gut geschafft den Umstieg auf eine völlig andere Plattform vor seinen Anwender quasi komplett verborgen zu halten und so lahm sind .NET-Programme nun auch wieder nicht. Ich bin daher immer noch der Meinung das Kompatibilität deutlich überschätzt wird, natürlich bedarf es dazu guter Emulatoren aber dafür gibt es in den letzten 20 Jahren Computer-Geschichte mehr als nur diese 4 Beispiele. Ein guter Off-Line-Code-Morpher, der sich auch so viel Zeit nimmt wie ein normaler Compiler, sollte auch auf ein ähnliches Ergebnis kommen wie ein normaler Compiler. Beim FX! gab es wimre die Option das der Morphing-Mechanismus im Hintergrund weiter arbeitet und die ganze EXE (und alle DLLs) gründlich umwandelt (und nicht nur den Code der gerade tatsächlich ausgeführt wird) und das Ergebnis dann auf der Festplatte abspeichert so dass das Programm bei allen folgenden Aufrufen sofort starten kann und mit voller Alpha-Performance läuft. Rosetta hatte doch bestimmt ähnliche Tricks auf Lager.

das können die meisten Emulatoren ja noch nichtmal heute!

Das hat beim 286 aber auch spezielle Gründe. Ich dachte eigentlich das BOCHS in diesem Punkt zwar langsam (wenn auch auf einer halbwegs aktuellen CPU nicht so langsam wie ein echter 286 von vor 30 Jahren) aber immerhin korrekt ist.


Grüße
Erik

[Svenska]

Hallo,

Emulation funktioniert nur, wenn ein enormer Performance-Unterschied zwischen der emulierten und der emulierenden Architektur liegen.

Dann kennst Du keine guten Emulatoren. Das Zauberwort heißt Code-Morphing.

Wollten wir uns nicht mal auf KISS beschränkten?

Das hat Transmeta ziemlich gut gekonnt (und das sogar ohne dass das OS das überhaupt bemerkt hat, nur die echte Host-CPU war nicht so wirklich der Bringer), auch Microsoft hat das unter Windows NT 4 mit dem damaligen FX! in ziemlich guter Performance geschafft

Also der einzige Rechner mit Transmeta-CPU, den ich (viel zu lange) in den Fingern hatte, war grausam. Wenn man den eine Stunde mit 486er-Architekturen zugeworfen hat, brauchte er fast fünf Minuten, um auf den Windows-98-Desktop zurückzukehren. Wenn sogar ein 486er mit 100 MHz schneller ist, als eine Transmeta-CPU mit dem fünffachen, dann kann die Emulation einfach nicht gut genug sein.

FX! ist meines Wissens ein zugekauftes Produkt gewesen (ob sie das Produkt oder die Firma gekauft hatten, weiß ich gerade nicht mehr), über die Performance kann ich nichts sagen; Alpha-Systeme waren aber meist mit besserer Peripherie ausgestattet. Du darfst aber nicht vergessen, dass bei den meisten Anwendungen die absolute Rechenzeit verglichen mit der Wartezeit auf Syscalls, Hardware, ... keine Rolle spielt und synthetische Benchmarks (für die Codemorphing wirklich gut funktioniert) keine sinnvollen Aussagen liefert.

Apple hat es mit Rosetta wohl ziemlich gut geschafft den Umstieg auf eine völlig andere Plattform vor seinen Anwender quasi komplett verborgen zu halten und so lahm sind .NET-Programme nun auch wieder nicht.

Der Umstieg von m68k zu PPC war einfach zu machen, da selbst ein 68040 wesentlich langsamer ist, als ein PowerPC gleicher Ära. Rosetta spielt durch "Universal Binaries" (m68k/PPC-Sprech: "Fat Binaries") nur eine untergeordnete Rolle. Außerdem laufen meines Wissens sowohl Rosetta als auch .net mit dynamischer Rekompilierung, d.h. das Programm ist nur bei der ersten Ausführung langsam, später wird nur noch nativer Code ausgeführt.

Darum sind das keine Emulatoren mehr, außerdem funktionieren sie nur für gewisse Randfälle.

Überhaupt spielt die genaue, wenn auch inzwischen überalterte PC-Plattformspezifikation eine große Rolle, denn ohne diese gäbe es uns hier nicht.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Wollten wir uns nicht mal auf KISS beschränkten?

Ja schon, aber nur wenn das eigentliche Ziel auch erreicht wird. Eine Lösung die mein Problem nicht löst ist keine Lösung und damit ist auch das KISS-Prinzip wirkungslos.

Wenn man den eine Stunde mit 486er-Architekturen zugeworfen hat, brauchte er fast fünf Minuten, um auf den Windows-98-Desktop zurückzukehren.

Das Problem von Transmetas Lösung war das es keine Persistenz für den gemorphten Code gibt, die Transmeta-CPUs hatten doch so einen extra RAM in dem zum einen die Code-Morphing-SW liegt und zum anderen eine Art Cache mit dem gemorphten Code und wenn dieser Cache voll ist müssen nun mal ein paar alte Dinge weichen (so sind Caches eben, schau Dir mal an wie QEMU seinen Cache verwaltet und dann wird Dir auffallen das Transmeta dieses Detail gar nicht mal so dumm umgesetzt hat). Hier sind Lösungen die den gemorphten Code auf der (unbegrenzten) HDD speichern können klar im Vorteil.

über die Performance kann ich nichts sagen; Alpha-Systeme waren aber meist mit besserer Peripherie ausgestattet. Du darfst aber nicht vergessen, dass bei den meisten Anwendungen die absolute Rechenzeit verglichen mit der Wartezeit auf Syscalls, Hardware, ... keine Rolle spielt und synthetische Benchmarks (für die Codemorphing wirklich gut funktioniert) keine sinnvollen Aussagen liefert.

Ich erinnere mich nur dass das anhand von aufwendigen Excel-Scripten und Photoshop-Batches durchgeführt wurde, klar sind das auch keine perfekten Benchmarks aber einem zeitgemäßem Pentium waren die Alpha-Resultate oft überlegen, sicher hätte hier ein PentiumPRO noch mal was holen können aber der war da noch nicht so arg verbreitet. Und wer das FX! damals konkret programmiert hat spielt doch auch keine Rolle, es ist ein Beispiel dafür das sowas funktionieren kann wenn man es ordentlich macht.

Rosetta spielt durch "Universal Binaries" (m68k/PPC-Sprech: "Fat Binaries") nur eine untergeordnete Rolle.

Diese "Fat Binaries" sind aber erst raus gekommen als sich die Anwendungshersteller mit Appels Plattformwechsel aktiv beschäftigt hatten, alles was vorher schon da war lief per Rosetta.

Außerdem laufen meines Wissens sowohl Rosetta als auch .net mit dynamischer Rekompilierung, d.h. das Programm ist nur bei der ersten Ausführung langsam, später wird nur noch nativer Code ausgeführt.

Das hab ich doch schon gestern geschrieben, es geht mir doch gerade darum das so ein Emulator lieber mehr Energie in die Optimierung stecken soll aber dafür nur ein einziges mal.

Darum sind das keine Emulatoren mehr

Das ist Wortglauberei (da fällt mir ein das ich schon lange nichts mehr von der Kalibrierung meiner Haarspalter-Gold-Waage gehört habe, da muss ich gleich morgen Früh mal hinterher telefonieren, kann doch nicht sein das ich hier völlig unvorbereitet in solche speziellen Wortgefechte gerate), sorry, aber es ist doch völlig wurscht wie das heißt solange es eine gute Lösung für ein echtes Problem ist.
Solange Intel mit jedem x86-CPU-Kern auch alle Altlasten mitschleppen muss wird sich x86 auch nie in den ganz kleinen bzw. ganz sparsamen Systemen behaupten können (so groß kann Intels technologischer Vorsprung bei der Chipherstellung nun auch wieder nicht werden), ein gut optimierter ARM Cortex-A9 kommt mit einem Bruchteil an Transistoren und Energieverbrauch aus gegenüber einem Atom-x86 und kann performancemäßig trotzdem noch recht gut mithalten. Wenn die Performance wirklich wichtig ist werden eben mehrere Cortexe zusammengepackt und erreichen dann auch mehr CPU-Leistung bei trotzdem immer noch kleinerem Energie- und Silizium-verbrauch.
Ich behaupte das wenn Intel wirklich in diesen Markt rein will dann wird Intel aus x86 einiges raus werfen und das dann in SW emulieren müssen.


Grüße
Erik

[MasterLee]

Wenn du sehr lange Akkulaufzeit brauchst dann kauf dir am besten ein Tablet mit zwei Akkuschächten, bei dem sich die Akkus im Betrieb tauschen lassen.
Und was die Entwicklung auf Android angeht das einzig halbwegs brauchbare ist zur Zeit: java-ide-droid
Ansonsten Fasziniert mich ja immer noch das Nokia N8:

[Svenska]

Das Problem von Transmetas Lösung war das es keine Persistenz für den gemorphten Code gibt, die Transmeta-CPUs hatten doch so einen extra RAM in dem zum einen die Code-Morphing-SW liegt und zum anderen eine Art Cache mit dem gemorphten Code

Ja, und dafür haben die einerseits ohnehin knappen System-RAM genommen, andererseits braucht die CPU zum Funktionieren dann zusätzliche Speicherbandbreite.
Die hätten meiner Meinung nach lieber mal die native Architektur öffnen sollen, meinetwegen auch zusätzlich zum x86-Befehlssatz.

Diese "Fat Binaries" sind aber erst raus gekommen als sich die Anwendungshersteller mit Appels Plattformwechsel aktiv beschäftigt hatten, alles was vorher schon da war lief per Rosetta.

Naja, für den Softwarehersteller ist es ein einmaliges Rekompilieren und dann ist das Problem gelöst. Dafür muss Rosetta nicht sonderlich schnell sein - ist es aber trotzdem.

Außerdem laufen meines Wissens sowohl Rosetta als auch .net mit dynamischer Rekompilierung, d.h. das Programm ist nur bei der ersten Ausführung langsam, später wird nur noch nativer Code ausgeführt.

Das hab ich doch schon gestern geschrieben, es geht mir doch gerade darum das so ein Emulator lieber mehr Energie in die Optimierung stecken soll aber dafür nur ein einziges mal.

Also willst du einfach einen dynamischen Compiler, der zur Laufzeit den Code so hinbiegt, dass er auf der gerade vorhandenen Architektur läuft und dafür Kompatiblität in Hardware opfern.

Solange Intel mit jedem x86-CPU-Kern auch alle Altlasten mitschleppen muss wird sich x86 auch nie in den ganz kleinen bzw. ganz sparsamen Systemen behaupten können (so groß kann Intels technologischer Vorsprung bei der Chipherstellung nun auch wieder nicht werden),

Die Architektur war und ist auch nicht dafür gebaut worden. Noch nie. Nur, weil dein Hammer nicht passt, setzt du dich auch nicht mit der Feile hin und bastelst so lange dran rum, bis er geht. Selbst wenn, danach taugt er nicht mehr für den ursprünglichen Zweck.

Eher kaufst du dir einen passenden Hammer. Und der ARM-Hammer muss halt nicht kompatibel zu den Urzeiten sein.

Ich hatte mal mit einem Terminal zu tun (mit Win NT4 Embedded), wo an der Kompatiblität gespart hatte und GRUB nebst anderen Bootloader direkt der Länge nach hingeschlagen ist, wenn man das Teil booten wollte. Der Preis war, dass man darauf ohne extremen Aufwand kein anderes Betriebssystem draufmachen konnte. Das ist aber genau das, was ich von einem PC-kompatiblen erwarte, im Gegensatz zu einem Tablet.

Wenn die Performance wirklich wichtig ist werden eben mehrere Cortexe zusammengepackt und erreichen dann auch mehr CPU-Leistung bei trotzdem immer noch kleinerem Energie- und Silizium-verbrauch.

Da scheiterst du an NUMA und der heutigen Informatik. Viele Probleme sind damit nicht so effizient lösbar, wie man es möchte. ARM optimiert aber gewaltig in die Richtung, einen Cortex-A15 neben einen -A7 zu schalten und damit energieeffizientes Scheduling zu benutzen. Zumal die aktuellen schnellen ARMs wesentlich mehr Energie pro Rechenleistung fressen als die kleineren und wenn du einen aktuellen Cortex mit 2-4 GHz takten wolltest, bist du garnicht mehr so weit weg vom Energiebedarf von x86ern.

Ich behaupte das wenn Intel wirklich in diesen Markt rein will dann wird Intel aus x86 einiges raus werfen und das dann in SW emulieren müssen.

Wer sagt denn, dass die das nicht tun? Mikrocode gibt es jedenfalls schon, das BIOS ist ohnehin chipsatz- und mainboardspezifisch und dessen Bootstrap-Code kann ja sonstwie gestrickt sein. Den Mikrocode in die CPU zu werfen, die dann so tut, als wäre sie im Real Mode, reicht doch aus...

Zumal: Selbst, wenn sie es in SW emulieren, tut das weder der Performance noch der Kompatiblität einen Abbruch. Den Kram nutzt eh kaum jemand.

Gruß,
Svenska

[Tobiking]

Um mal auf das ursprüngliche Thema zurück zu kommen, ich hab auch mit dem Gedanken gespielt mir nen Asus Transformer Prime zuzulegen. Da sich der Release jetzt aber auf nächstes Jahr verschoben hat, hab ich das erstmal zurückgestelt. Ich habe mich aber schon informiert, dass es auf dem Vorgänger möglich ist ein richtiges Linux zu installieren (siehe http://stream0.org/2011/11/24/dual-booting-android-and-linux-on-asus-transformer-part-two/). Wird sich zeigen wie das beim Nachfolger aussieht.

[Dimension]

Gibt es denn die Option auf einem Android Device beliebigen ARM-Bytecode auszuführen und evtl auf das ABI zuzugreifen? Dann könnte man u.U. ja ein richtiges Linux darauf portieren.
Wollte iich schon immer mal fragen.

[Svenska]

Grundsätzlich ja, aber nicht praktikabel.

Um ein anderes Betriebssystem (also auch einen normalen Kernel) auf einem Android-Gerät zu booten, musst du es vor dem Android-Start zur Ausführung bringen. Also musst du den Bootloader dazu bringen, deinen eigenen Kernel zu booten. Inzwischen haben die meisten Hersteller allerdings erklärt, den Bootloader nicht mehr (komplett) zu sperren, vorher war das meist an kryptographische Signaturen gebunden.

Andererseits basiert Android auf Linux und kann daher Linux-Anwendungen ausführen. Theoretisch kannst du also den Android-Kernel nehmen und darauf ein normales Userland laufen lassen. Ob das praktikabel ist, weiß ich nicht.

Da es keine vollständige Plattformspezifikation der Geräte gibt, wirst du keine Freude daran haben, einen eigenen Kernel für Consumergeräte zu stricken. Wenn du fertig ist, gibt es das Gerät vermutlich nicht mehr zu kaufen (oder zumindest einen inkompatiblen Nachfolger).

Gruß,
Svenska