Hallo,
Ja, und dafür haben die einerseits ohnehin knappen System-RAM genommen, andererseits braucht die CPU zum Funktionieren dann zusätzliche Speicherbandbreite.
Ja, die Idee ist gut aber die reale Umsetzung hatte durchaus noch so ihre Tücken. Es gab ja auch extra Transmeta-CPUs mit 2 Speichercontrollern, einer für den normalen RAM und einer für die Code-Morphing-SW und den Cache.
Die hätten meiner Meinung nach lieber mal die native Architektur öffnen sollen, meinetwegen auch zusätzlich zum x86-Befehlssatz.
Hatten die das nicht auch? Wenn nicht dann hätten sie es auf jeden Fall tun sollen, ich wette Linux wäre keine 6 Monate später drauf gelaufen und hätte vielleicht auch mal zeigen können was in der Transmeta-CPU wirklich drin steckt. Zumindest wäre es mal interessant zu sehen was passiert wenn sich ein fremdes CPU-Kuckucksei im x86-Nest breit macht.
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.
Ja, genau das meine ich. Aus meiner Sicht wäre 3D-Now bei den AMD-CPUs dafür ein guter Kandidat, das ist defacto ausgestorben und trotzdem muss AMD diese Befehle irgendwie noch unterstützen und ich wette AMD gibt sich keine besondere Mühe das sehr effizient zu tun (das würde ja Entwicklungszeit und Transistoren kosten) so das ich der Meinung bin das man 3D-Now lieber per Code-Morphing auf SSE abbilden sollte (so viel langsamer als mit schlecht gepflegter HW dürfte das auch nicht werden). Im Prinzip ist doch das was FlashBurn mit seiner Spezial-Page für den Syscall macht auch nur eine simple Vorstufe von Code-Morphing, warum dann nicht gleich das Executable nehmen und alle INT 0x80 Befehle gegen SYSCALL o.ä. austauschen? Und wenn das Code-Morphing aus Power-PC-Code welchen für x86 erzeugt ist das im Prinzip auch nicht so viel anders nur das eben eine Abstraktionsebene höher Disassembliert und danach wieder richtig neu Assembliert (mitsamt anständigen Optimierungen) werden muss. Genau das ist es auch was ich an ARMs Stelle machen würde wenn die Kompatibilität doch mal an einer Stelle nicht gewährleistet werden kann. Bei Micro-Controllern spielt sowas keine Rolle da der Code eh spezifisch kompiliert wird aber überall dort wo der Konsument vielleicht mal noch ältere SW (z.B. Apps die vor Jahren mal Geld gekostet haben und ihren Job noch immer gut machen) weiter nutzen möchte ist das IMHO ein guter Weg.
Nur, weil dein Hammer nicht passt, setzt du dich auch nicht mit der Feile hin und bastelst so lange dran rum, bis er geht.
Netter Vergleich, ich fürchte nur das Intel an x86 so lange feilen wird bis es doch irgendwie für Embedded taugt.
Ob das Ergebnis dann immer noch so viel mit x86 zu tun hat wie der Name suggeriert steht auf einem anderen Blatt, ich persönlich denke ja dass das gar nicht funktionieren kann und bin deswegen der Meinung das Intel die fehlende Kompatibilität dann lieber in SW mitliefern sollte.
Das ist aber genau das, was ich von einem PC-kompatiblen erwarte, im Gegensatz zu einem Tablet.
Also ich persönlich erwarte das auch von einem Tablet und wenn die Industrie mein Geld haben will das muss sie mir auch so ein Tablet bieten ansonsten treffe ich als mündiger Verbraucher meine Kaufentscheidung eben anders.
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.
Das ist durchaus richtig aber die Anzahl der benötigten Transistoren ist bei ARM immer noch deutlich kleiner und das schlägt sich spürbar im Kaufpreis nieder. Nebst dessen das ich noch keinen Quad-Core-ARM mit über 100W gesehen habe.
Wer sagt denn, dass die das nicht tun?
Niemand, ich vermute sie werden das auch irgendwann mal machen, ich bin ja auch der Meinung das es Intels einzigste echte Option ist um dieses Ziel zu erreichen.
Mikrocode gibt es jedenfalls schon
Also ich glaube Du überschätzt da die Möglichkeiten des Micro-Code ein ganz klein wenig.
... hilft nichtmal mehr ein Backofen.
Das hägt sehr von den Fähigkeiten dieses Backofens ab. Wenn der über eine schnelle und dynamische Temperaturregelung verfügt dürfte der noch im Geschäft sein.
Aber für mein Projekt hab ich mir auch schon mal überlegt ob ein selbst gebauter Reflow-Ofen nicht eine gute Option wäre.
Grüße
Erik
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: Auf Android entwickeln (Gelesen 21335 mal)