Windows 8 läuft auch auf ARM-Prozessoren

AW: Windows 8 läuft auch auf ARM-Prozessoren

Wieviel wird denn heute schon noch in Assembler geschrieben :huh:
Alles, was du nur in Ring 0 machen kannst, ist bei keiner mir bekannten Programmiersprache oberhalb von Assembler enthalten. Du kannst mich gerne eines besseren belehren.
Hier mal eine kleine Auswahl:
- benutzen von Port -> die Grundlage eines jeden Hardwaretreibers
- in MSR und andere Spezialregister schreiben oder diese auslesen; wie beispielsweise IDTR für die Interrupt-Tabelle oder Register für den Wechsel von Ring 3 (Nutzermodus) zu Ring 0 (Kernelmodus) wie das SysEnter-Register

Auch andere Dinge sind meines Wissens nach nur mit Assembler möglich:
- Zustand von bestimmten Registern sichern -> für den Wechsel von Threads/Prozessen
- spezielle Instruktionen verwenden, z.B. von (I)SSE4, um eine Beschleunigung zu erreichen
Zugegeben, letzteres wird schon von manchen Compilern als Optimierung verwendet, aber der Mensch weiß doch manchmal immer noch am Besten, was er möchte. Außerdem kann so auch beides umgesetzt werden, einmal eine speziell an die Architektur angepasste schnelle Version und dann eine Version, die immer läuft. Beim Programmstart wird schnell getestet, ob das schnelle läuft und falls nicht, wird die alte Variante genommen. Mir ist bisher kein Compiler bekannt, der dies mit macht.

Die Beschleunigung, die durch Verwendung spezieller Befehle erreicht werden kann, ist nicht zu unterschätzen. Ich habe beispielsweise mal einen Teil von DES mit ISSE4 umgesetzt. Mein Assemblercode war kürzer als mein normaler C-Code. Zugleich hat die schnellste, andere Umsetzung, die ich gesehen habe, viermal mehr Zeit benötigt.
Es gibt also genug, was mit Assembler geschrieben ist und bei Betriebssystemen gibt es Dinge, die nicht anders umgesetzt werden können.

Auf der anderen Seite überrascht es vllt. viele, dass bei Windows schon seit vielen Jahren - auch schon vor der NT-Architektur - Mechanismen für andere Prozessorarchitekturen gibt. So hat das PE-Format, welches bei Windows z.B. bei EXE, DLL und SYS-Dateien verwendet wird, auch eine Angabe über die Architektur. Die Liste dabei ist relativ lang. Dazu gehören auch verschiedene ARM-Prozessoren, MIPS, ... . Microsoft hat die auch gepflegt. Das letzte Update gab es am 21.09.2010. Da wurde beispielsweise ARMv7 eingepflegt, was wohl die neuste ARM-Architektur ist - nicht zu verwechseln mit der Prozessorfamilie ARM7.
Auch gibt es verschiedene API-Funktionen, mit der beispielsweise die vorhandene Prozessor-Architektur ermittelt werden kann. In Visual Studio sind verschiedene Zielplattformen einstellbar, darunter MIPS und ARM.

Folglich ist es für viele Software-Entwickler einfach möglich, ihre Programme auch für die ARM-Architektur anzubieten. Nur wo Assembler genutzt wird, muss noch umprogrammiert werden. Dies wird Windows selber, verschiedene Treiber und einige beschleunigte Programme sein.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Alles, was du nur in Ring 0 machen kannst, ist bei keiner mir bekannten Programmiersprache oberhalb von Assembler enthalten.

Wir reden hier von Anwendungssoftware. Die hat im Ring 0 ja wohl mal gar nichts zu suchen.
Treiber und Betriebssystem enthalten natürlich Assembler-Abschnitte, aber die müssen ja so oder so an eine andere Hardware angepasst werden und werden es hier auch von Microsoft bzw. den Hardwareherstellern. Interessant ist, wie Softwareentwickler auf die so entstehende Plattform reagieren und da sage ich:
Die Umsetzung bestehender x86-Windows-Anwendersoftware auf ein ARM-System mit einem Betriebssystem, das alle Windows-Schnittstellen in gleicher Weise zur Verfügung stellt, sollte in 90% der Fälle nicht wesentlich mehr als eine Rekompilierung erfordern.

- spezielle Instruktionen verwenden, z.B. von (I)SSE4, um eine Beschleunigung zu erreichen

Sicher?
Dachte eigentlich, dass die SSE-Funktionen aus jedem Ring genutzt werden können und von (guten) Compilern sogar automatisch integriert werden.

Außerdem kann so auch beides umgesetzt werden, einmal eine speziell an die Architektur angepasste schnelle Version und dann eine Version, die immer läuft. Beim Programmstart wird schnell getestet, ob das schnelle läuft und falls nicht, wird die alte Variante genommen. Mir ist bisher kein Compiler bekannt, der dies mit macht.

Hardwarenahe Optimierungen sind natürlich eine schöne Sache, aber wie du ja selbst schreibst: Oft besteht ohnehin ein Fallback oder man hat nachträglich Teile, die in Hochsprache/automatischer Kompilierung zu lahm waren, durch handgeschriebenen Assemblercode getauscht. In diesen Fällen steht aber somit ein Hochsprachencode zur Verfügung, den man z.B. durch einen ARM-Win8-Compiler jagen könnte. Das Ergebniss wäre nicht so effizient, wie die optimierte x86-Variante, aber es sollte lauffähig sein - und das ist ein ganz wichtiger Punkt.
Alternative Plattformen kämpfen zu 95% nicht damit, dass sie ineffizienter oder langsamer wären, als Wintel, sondern damit, dass der Nutzer irgendwelche (oft ja nichtmal fordernden Anwendungen) nutzen will, diese aber für die alternative Plattform nicht bekommt. Wenn die Entickler die Möglichkeit haben, eine zwar langsamere, aber funktionale Version der Software in einem zweiten Markt anzubieten und wenn ihnen das nicht mehr als eine Rekompilierung abverlangt, dann werden sie das machen. -> Ein riesiger Schritt nach vorn für die alternative Plattform.

Auf der anderen Seite überrascht es vllt. viele, dass bei Windows schon seit vielen Jahren - auch schon vor der NT-Architektur - Mechanismen für andere Prozessorarchitekturen gibt. So hat das PE-Format, welches bei Windows z.B. bei EXE, DLL und SYS-Dateien verwendet wird, auch eine Angabe über die Architektur. Die Liste dabei ist relativ lang. Dazu gehören auch verschiedene ARM-Prozessoren, MIPS, ... . Microsoft hat die auch gepflegt. Das letzte Update gab es am 21.09.2010. Da wurde beispielsweise ARMv7 eingepflegt, was wohl die neuste ARM-Architektur ist - nicht zu verwechseln mit der Prozessorfamilie ARM7.
Auch gibt es verschiedene API-Funktionen, mit der beispielsweise die vorhandene Prozessor-Architektur ermittelt werden kann. In Visual Studio sind verschiedene Zielplattformen einstellbar, darunter MIPS und ARM.

Folglich ist es für viele Software-Entwickler einfach möglich, ihre Programme auch für die ARM-Architektur anzubieten. Nur wo Assembler genutzt wird, muss noch umprogrammiert werden. Dies wird Windows selber, verschiedene Treiber und einige beschleunigte Programme sein.

Viel Software greift afaik aber auch auf Schnittstellen von Windows zurück, oder?
Und da gibt es (mit Ausnahme der IA64-Version? weiß ich nicht) kein zweite Plattform neben x86, für die M$ ein vollkompatibles Windows veröffentlicht hat.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Meinem Verständnis nach ging es nicht um reine Anwender-Software. Es kann natürlich sein, dass ich das falsch verstanden habe. Reine Anwender-Software kommt bei Windows gar nicht in Ring 0. ;)
Und was das SSE angeht, das stand unter "Auch [...] nur mit Assembler möglich:", es bezog sich nicht mehr auf Ring 0.

Dein "einfach kompilieren und nur die Fall-Back-Variante nehmen" erfordert dennoch, dass man die architekturspezifischen Assembler-Befehle entfernt, ansonsten verweigert der Assembler mit Verweis auf unbekannte Befehle den Dienst. Folglich ist dann mehr Arbeit notwendig, als einfaches Kompilieren.

Zu den Schnittstellen habe ich gesagt, was Microsoft in Dokumentationen und Spezifikationen angibt. Dass sie aktuell außer x64, x86 und IPF keine andere vorkompilierte Version von Windows anbieten, ist eine andere Sache.

Ich wiederhole mich gerne noch einmal. Viele Anwendungssoftware wird durch ein einfaches Kompilieren auch auf ARM-Prozessoren mit Windows laufen. Ich wage sogar zu behaupten, dass man dies schon jetzt mit Visual Studio machen kann. Das einzige Problem könnte sein, dass ich nur eine Option für "ARM" aber keine für "ARMv7" bei mir gesehen habe. Ich schätze aber, dass Windows 8 eher auf letzterem laufen wird und da Microsoft beim PE-Format explizit einen Unterschied zwischen den beiden macht, wird es u.U. ähnlich wie mit "I386" und "AMD64" sein.
Dennoch muss am Betriebssystem und anderer Software, die Assembler nutzt, noch Dinge verändern. Und unterschätze die Anzahl der Software mit Assembler und überschätze die Optimierungsfähigkeiten der Compiler bzgl. spezieller Assemblerbefehle nicht!
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Ich hoffe das es auch irrgent wann auf desktop pc schaft!dann können auch andere hersteller wieder ausser intel u. amd cpu`s raus bringen!das währe echt klasse!:daumen::daumen::daumen::daumen::daumen:
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

naja wenn das neue system erst in 2 jahren kommen soll, dann hat sich auch mit sicherheit einiges getan auf dem mobilprozessor markt und die vorraussetzungen werden ganz andere sein als heute :daumen:
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Ich hoffe das es auch irrgent wann auf desktop pc schaft!dann können auch andere hersteller wieder ausser intel u. amd cpu`s raus bringen!das währe echt klasse!

Die Frage ist, wie lange es dauert, bis es irgendein Hersteller schafft, auf ARM Basis etwas zu entwickeln, was leistungsmäßig halbwegs mit aktuellen X86 Desktop CPUs mithalten kann...
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Sehr schön, dann fehlt jetzt nur noch eine Umsetzung auf PPC. :)

@Ruyven: Ein bekannter Informatiker meinte mal zu mir, dass er schon noch sehr viele Zeilen nachträglich im Assembler bearbeitet, da der optimierte Code um einiges effizienter ausgeführt werden kann als jeglicher Compiler eine Hochsprache jemals übersetzen könnte.

Ein Beispiel, dass ich dabei immer gern bringe, ist der Vergleich zwischen HTML-Code, der per MS Word, Dreamweaver und Co erstellt wird und der, der per Hand geschrieben wird. Letzterer ist oftmals nichtmal einen Bruchteil so lang und wird entsprechend schneller abgearbeitet.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Sehr schön, dann fehlt jetzt nur noch eine Umsetzung auf PPC.

Ja... schon seid Jahren...

@Ruyven: Ein bekannter Informatiker meinte mal zu mir, dass er schon noch sehr viele Zeilen nachträglich im Assembler bearbeitet, da der optimierte Code um einiges effizienter ausgeführt werden kann als jeglicher Compiler eine Hochsprache jemals übersetzen könnte.

Prinzipiell stimmt das zwar aber in der Praxis wird es doch nur selten gemacht da es den Aufwand meist nicht wert ist
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Ja... schon seid Jahren...

Was ich mich frage ist folgendes:
In jeder Rechnerarchitektur gibt es doch Äquivalente Anweisungen, nur dass meinetwegen Befehls- und Datenbits vertauscht sind bzw. erstere anders lauten. Wäre es da nicht möglich, mit einem speziellen Programm eine Software auf Assemblerbasis komplett und dauerhaft auf eine andere Architektur zu portieren? Schließlich ist die Laufzeitportierung von x86 auf IA64 auch möglich, wenn auch zeitintensiv, aber da es während der Programmausführung erst geschieht, isst dies auch nicht verwunderlich.
Afaik gibt es sogar SSE-Äquivalente bei PPC-CPUs.

Ich habe ein Video gesehen, wo jemand auf seiner PS3 Linux installierte und dann mittels VM-Software Windows XP startete! Allerdings dauerte allein das Hochfahren etwa 10min... :ugly: Das zeigt doch aber, dass eine Portierung prinzipiell möglich sein sollte (in der PS3 steckt ein PPC-CPU), aber während der Laufzeit doch arg Zeit benötigt (deshalb meine Frage im obigen Abschnitt).
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Ich habe ein Video gesehen, wo jemand auf seiner PS3 Linux installierte und dann mittels VM-Software Windows XP startete! Allerdings dauerte allein das Hochfahren etwa 10min... Das zeigt doch aber, dass eine Portierung prinzipiell möglich sein sollte (in der PS3 steckt ein PPC-CPU), aber während der Laufzeit doch arg Zeit benötigt (deshalb meine Frage im obigen Abschnitt).

Wurde sicher ganz einfach emuliert was auch die miese Geschwindigkeit zeigt
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Wurde sicher ganz einfach emuliert was auch die miese Geschwindigkeit zeigt

Dass das emuliert wurde, war mir schon klar. :ugly: Die Frage ist halt, ob man es dann nicht einfach permanent in emulierter Form auf einem Speichermedium ablegen könnte, so dass es künftig sofort ausführbar wäre. Wenn jemand mit entsprechenden Fachkenntnissen die ganze Sache durchzieht, würde da sicherlich auch etwas durchaus brauchbares bei herauskommen.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Sicher wird es möglich sein aber damit würde man den Code sicher extrem aufblasen und das Programm damit weiterhin einerseits wirklich massiv verlangsamen andererseits auch den Speicherbedarf vervielfachen
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Dass das emuliert wurde, war mir schon klar. :ugly: Die Frage ist halt, ob man es dann nicht einfach permanent in emulierter Form auf einem Speichermedium ablegen könnte, so dass es künftig sofort ausführbar wäre. Wenn jemand mit entsprechenden Fachkenntnissen die ganze Sache durchzieht, würde da sicherlich auch etwas durchaus brauchbares bei herauskommen.
Wenn ich das richtig verstanden habe, dann meinst du also das man ein Programm quasi einmal "emuliert" und dann in dieser Form abspeichert oder? So einen ähnlichen Ansatz gibt es zumindest schon im .net Framework wenn ich mich recht erinnere.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Wenn ich das richtig verstanden habe, dann meinst du also das man ein Programm quasi einmal "emuliert" und dann in dieser Form abspeichert oder? So einen ähnlichen Ansatz gibt es zumindest schon im .net Framework wenn ich mich recht erinnere.

Ja genau so meine ich das... Als würde man einen Text übersetzen und auf ein neues Blatt Papier schreiben. Und wie gesagt gibt es doch in allen Architekturen Befehle mit identischen Funktionen. Es sollte doch also fast schon von einem Laien möglich sein, die Befehle umzuschreiben?
 
Zuletzt bearbeitet:
AW: Windows 8 läuft auch auf ARM-Prozessoren

Mein Fachwissen auf diesen Gebiet ist jetzt nicht so dolle, aber wie gesagt .net verfolgt soweit ich weiß genau so einen Ansatz. In diesen Fall wird ein Zwischencode auf der Zielmaschine in nativen Code umgewandelt, so dass dieser nicht jedesmal interpretiert werden muss.

Von der ersten oberflächlichen Betrachtung her, würde ich dir Recht geben, die Frage die sich mir aber sofort stellt ist, wie ist das ganze Rechlich zu bewerten?
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Dass das emuliert wurde, war mir schon klar. :ugly: Die Frage ist halt, ob man es dann nicht einfach permanent in emulierter Form auf einem Speichermedium ablegen könnte, so dass es künftig sofort ausführbar wäre. Wenn jemand mit entsprechenden Fachkenntnissen die ganze Sache durchzieht, würde da sicherlich auch etwas durchaus brauchbares bei herauskommen.

Es ist nicht (ohne sehr großen Aufwand) möglich, die Logik hinter einem kompilierten Programm zu erfassen. D.h. ganz basale Funktionen könntest du vermutlich permanent umsetzen - aber welcher Programmteil wann welche Daten von welchem andern Teil übernimmt und an spezielle Einheiten dieser Architektur weitergibt, das dürfte schwer zu erkennen zu sein. Man könnte also höchstens für Funktionen, die 100%iges Gegenstück in der anderen Architektur haben, den Befehlsaufruf ersetzen. Aber alles, was etwas komplexer wird oder eine Befehlskombination darstellt oder gar auf besimmte Einheiten zurückgreift (bei Portierung auf x86 z.B.: weitere Register, die x86 gar nicht hat), müsste nach Bedarf emuliert werden. Man spart sich also gerade das, was in einer Emulation leicht und schnell zu bewerkstelligen ist und behält den problematischen Rest.
Unterm Strich würde ich von einem "preemulierten" Programm einen kleineren Vorsprung erwarten, als ihn z.B. die hardware-x86-Emulation der ersten Itanics brachte. Also einen unzureichend kleinen.


Mein Fachwissen auf diesen Gebiet ist jetzt nicht so dolle, aber wie gesagt .net verfolgt soweit ich weiß genau so einen Ansatz. In diesen Fall wird ein Zwischencode auf der Zielmaschine in nativen Code umgewandelt, so dass dieser nicht jedesmal interpretiert werden muss.

Wobei dieser Ansatz aber letztlich ganz verhindert, dass man Software auf eine Architektur optimiert. Automatisch angepasster Code in einem entsprechenden Framework dürfte, je nach dessen Ausgestaltung, irgendwo zwischen Java (Programm läuft komplett auf einer virtuellen Maschiene) und nichtoptimierten, automatisch kompilierten (z.B.) C++ Code liegen (nicht optimiert, aber passend zum System kompiliert)

Solange wir von einem Konvertierungsschritt beim Entwickler ausgehen, entspricht die Qualität der automatischen Ansätze also dem, was bereits möglich ist.

Von der ersten oberflächlichen Betrachtung her, würde ich dir Recht geben, die Frage die sich mir aber sofort stellt ist, wie ist das ganze Rechlich zu bewerten?

Solange die emulierten Versionen nicht getrennt vom Original vertrieben werden, sollte das eigentlich egal sein. Afaik (butthatsnotmuch) sind AGBklauseln, die eine Veränderung von Code zum Eigenbedarf verbieten, ungültig und der Rechteinhaber darf vor Auslieferung sowieso machen, was er will.
 
AW: Windows 8 läuft auch auf ARM-Prozessoren

Wobei dieser Ansatz aber letztlich ganz verhindert, dass man Software auf eine Architektur optimiert. Automatisch angepasster Code in einem entsprechenden Framework dürfte, je nach dessen Ausgestaltung, irgendwo zwischen Java (Programm läuft komplett auf einer virtuellen Maschiene) und nichtoptimierten, automatisch kompilierten (z.B.) C++ Code liegen (nicht optimiert, aber passend zum System kompiliert)

Solange wir von einem Konvertierungsschritt beim Entwickler ausgehen, entspricht die Qualität der automatischen Ansätze also dem, was bereits möglich ist.
Klar, da stimme ich dir voll und ganz zu und das ganze wird auch durch meine Erfahrung mit diesen System bestätigt.
 
Zurück