DevPandi schrieb:
Intel hat mit
AVX10 sowie APX hier bereits zu Teilen die richtigen Erweiterungen in Petto, die einige der Limitierungen und Problemen der x86-ISA weitgehend "ausmerzen". Klar, wichtig ist hier für Intel, dass auch AMD zeitnah mitzieht, doch die Hauptlimitierungen der ISA werden damit angegangen.
AVX10 ist ja in erster Linie eine Zusammenfassung der CPUID feature flags, wenn ich es richtig sehe.
Und auch bei APX geht es, wenn ich es richtig verstanden habe, ausschließlich um die AVX-Register. Klar, man kann dann alte AVX/AVX2-Programme einmal neukompilieren und nutzt dann automatisch die 16 zusätzlichen Register, ohne die Abwärtskompatiblität zu AVX/AVX2 aufzugeben. Das ist alles schön und gut, aber für Programme ohne AVX bringt es nichts?!
Das Problem ist AVX selbst. Alle paar Jahre kommt ein neues feature set und die Anpassung der Software ist eben nicht immer trivial, wenn man Abwärtskompatiblität wahren will. Deswegen wird es meines Wissens vor allem in spezieller Software eingesetzt, wo es enorme Leistungssprünge ermöglicht. Die meisten Brot- und Butterprogramme werden die Komplexität aber wohl eher vermeiden wollen und Distributoren wollen auch nicht x verschiedene binaries ausliefern, ... Sicherlich kann AVX10 helfen, aber dann gibt es trotzdem noch Problemstellungen, die gar nicht oder nur kaum von SIMD-Befehlen profitieren.
Ich sehe das alles also etwas kritischer. Aber ich lasse mich gerne eines Besseren belehren
sikarr schrieb:
Ist die 16Bit Funktionalität denn noch gegeben?
Kurz gesagt: Ja.
sikarr schrieb:
Ich dachte WinXP war das letzte OS was noch 16Bit Code ausführen konnte?
Zumindest für die 32-Bit-Version gilt das. Es ist eben etwas komplizierter. Die Abwärtskompabilität ist aber immer nur "eine Stufe" gegeben.
Bei AMD64 gibt es zwei Modi, den legacy mode und den long mode.
Im legacy mode hast du im Grunde einen 32-bittigen x86-Prozessor mit real mode (16 Bit) und protected mode (32 Bit). Ohne weiteres Zutun vom OS (oder UEFI, oder dem Bootloader) bist du immer zuerst im legacy mode. Da kannst du auch ein 16-Bit-OS nutzen, oder eben ein 32-Bit-OS, genau wie eben bei klassischen i386-Prozessoren. Genau wie dort ist es auch möglich, 16-Bit-Programme im protected mode auszuführen, dafür gibt es den Virtual-8086-Mode. Kompliziert, oder? So war das aber schon seit dem 386 üblich...
Wenn das OS (oder UEFA/der Bootloader) proaktiv in den long mode geht (was jedes 64-Bit OS tut), dann sieht die Welt etwas anders aus. Hier gibt es den normalen 64-Bit-Modus und den compatiblity mode. Der Betriebssystem muss letzteren unterstützen und ermöglicht die Ausführung von 32-Bit-Programmen in einer protected mode-Umgebung, die recht kompliziert in die AMD64-Architektur eingebettet ist (was insb. das Paging betrifft) und für das jeweilige Programm vom OS aktiviert werden muss.
Diese Komplexität hatte den Weg für den Erfolg von AMD64 geebnet, weil man erstmal ohne Einschränkungen genau seine Software weiterverwenden konnte (legacy mode). Gleichzeitig konnte man aber auch auf ein 64-Bit-OS umsteigen, sobald man keine 16-Bit-Software (mehr) eingesetzt hat.
Intel wollte ja damals schon mit Itanium auf eine neue Architektur umsteigen, die konnte den x86 protected mode aber nur emulieren. Ergo hätte alles neu gemusst: Betriebssystem, Treiber, performancekritische Programme. War daher kein Erfolg und man hat es aufgegeben und stattdessen AMD64 adaptiert.
Die alten Zöpfe nun trotzdem loszuwerden ist auch Teil eines Intel-Projekts, das hat
@DevPandi ja schon angesprochen. Der legacy-Mode wird dann gestrichen, was nicht ganz trivial ist, weil alle x86 im real mode starten müssen, um BIOS-kompatibel zu sein. Aber die wenigsten werden heute noch 32-Bit-Betriebssysteme oder älter auf topmoderner Hardware einsetzen, deshalb ist es grundsätzlich sinnvoll.