Die Sprache C wurde für UNIX verwendet, um Portabilität zu erreichen - ein und dasselbe C-Programm, das mit verschiedenen Compilern kompiliert wurde, erzeugt unterschiedliche Maschinenbefehle. Wie kommt es, dass das Windows-Betriebssystem sowohl auf Intel- als auch auf AMD-Prozessoren laufen kann?
AMD- und Intel-Prozessoren(*) haben eine große Anzahl von Befehlen gemeinsam, so dass es für einen Compiler oder Assembler möglich ist, Binärcode zu schreiben, der auf beiden "gleich" läuft.
Allerdings haben verschiedene Prozessorfamilien, sogar von einem Hersteller, ihre eigenen Befehlssätze, die gewöhnlich als "Erweiterungen" oder ähnliches bezeichnet werden. Abgesehen vom x87-Coprozessor war das erste Mal, dass ich mich daran erinnere, dass dies ein Marketingargument war, als plötzlich alles "mit MMX(TM)-Technologie" lief. Binärcode, der auf einem beliebigen Prozessor laufen soll, muss entweder Erweiterungen vermeiden oder den CPU-Typ erkennen, bevor er sie verwendet.
Intels Itanium 64-Bit-Architektur unterschied sich völlig von AMDs x86-64-Architektur, so dass ihre 64-Bit-Angebote eine Zeit lang nicht kompatibel waren (und Itanium war nicht mit x86 vergleichbar, während x86-64 den Befehlssatz um 64-Bit-Befehle erweiterte). Intel hat zuerst geblinzelt und x86-64 übernommen, obwohl es immer noch ein paar Unterschiede gibt: http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
Windows verwendet wahrscheinlich den gemeinsamen x86- oder x86-64-Befehlssatz für fast den gesamten Code. Es würde mich nicht wundern, wenn verschiedene Treiber und Codecs in mehreren Versionen ausgeliefert werden und die richtige Version ausgewählt wird, sobald die CPU abgefragt wurde.
(*) Tatsächlich stellt Intel verschiedene Arten von Prozessoren her oder hat sie hergestellt, darunter auch ARM (Intels ARM-Prozessoren hießen XScale, aber ich glaube, sie haben dieses Geschäft verkauft). Und AMD stellt auch andere Prozessoren her. Aber wir wissen, welche Intel/AMD-Prozessoren Sie meinen :-)
+1. Intern behandeln AMD und Intel diese gemeinsamen Befehle im Allgemeinen recht unterschiedlich: Einige Befehle können auf der einen Architektur viel langsamer ausgeführt werden als auf der anderen.
Genau richtig, und so ist es auch bei Linux. Ich bin ein Linux-Kernel-Hacker, und wenn Sie jemals Ihren eigenen Linux-Kernel rekompiliert haben, werden Sie feststellen, dass Sie eine Vielzahl von CPU-Typen ansteuern können, und natürlich führt die Auswahl des falschen Typs und dessen Installation zu einem Kerndump oder einem hängenden System. Schöner Bericht von onebyone über diesen Fall!!!
Intel stellte den RISC i860 ungefähr zeitgleich mit dem Aufkommen der x86-Serie her... natürlich wissen wir, welcher überlebt hat und welcher nicht :)
Wie Sie vermuten, haben die Mainstream-Prozessoren von Intel und AMD den gleichen Befehlssatz.
Windows läuft beispielsweise nicht auf ARM- oder PowerPC-Chips, da es in gewisser Weise vom zugrunde liegenden Befehlssatz abhängig ist.
Der größte Teil von Windows ist jedoch in C++ geschrieben (soweit ich weiß), was auf andere Architekturen übertragbar sein sollte. Windows NT lief sogar auf PowerPC und anderen Architekturen .
Und sehen Sie sich den Linux-Kernel an, ein Betriebssystem, das auf vielen Architekturen läuft, sogar mit unterschiedlichen Befehlssätzen. Während der C-Code portabel ist, muss ein Großteil des Assemblers für jedes Ziel geändert werden.
Die XBox 360 verwendet einen modifizierten Windows 2000-Kernel, der auf einer PPC-Architektur läuft. Ich bin mir ziemlich sicher, dass Windows genauso portabel ist wie andere Betriebssysteme da draußen, es gibt nur keinen großen Anreiz für Microsoft, der Öffentlichkeit andere Versionen zur Verfügung zu stellen (für etwa zwei Kunden oder so).
Diese Antwort ist größtenteils richtig, außer im Fall von SIMD-Befehlssätzen. Die Dinge beginnen zu divergieren, sobald man 3DNow!, SSE1/2/3 usw. hinzumischt, aber das ist auch der Grund, warum x86-Compiler diese Befehlssätze im Allgemeinen nicht unterstützen.
Intels 80x86-CPUs und AMDs 80x86-CPUs sind "größtenteils gleich", aber einige Dinge sind völlig unterschiedlich (z.B. Erweiterungen für virtuelle Maschinen - SVM vs. VT-x) und einige Dinge (Erweiterungen) können unterstützt werden oder auch nicht. Einige Dinge sind jedoch auch auf verschiedenen CPUs desselben Herstellers unterschiedlich (z.B. unterstützen einige Intel-Chips AVX2 und andere nicht).
Es gibt mehrere Möglichkeiten, mit diesen Unterschieden umzugehen:
nur die gemeinsame Untermenge verwenden, damit derselbe Code auf allen 80x86-CPUs läuft (z. B. wie ein 8086-Chip behandeln).
eine Teilmenge von Merkmalen verwenden, die für eine Reihe von CPUs gemeinsam sind, so dass derselbe Code auf allen 80x86-CPUs in diesem Bereich läuft. Dies ist sehr häufig der Fall (z. B. "diese Software erfordert eine 80x86-CPU (und ein Betriebssystem), das 64-Bit-Erweiterungen unterstützt").
Tests zur Installationszeit verwenden. Zum Beispiel könnte es 4 verschiedene Kopien von Software geben (kompiliert für 4 verschiedene CPU-Bereiche), wobei das Installationsprogramm entscheidet, welche Kopie für den Computer, auf dem die Software installiert wird, sinnvoll ist.
Laufzeittests verwenden. Zum Beispiel kann der Code die CPUID Handlungsanweisung if( AVX2_is_supported() ) { set_function_pointers_so_AVX2_is_used(); } else {set_function_pointers_so_AVX2_is_not_used(); } . Hinweis: Einige Compiler (Intels ICC) können automatisch Code erzeugen, der Laufzeittests durchführt.
Diese Optionen schließen sich nicht gegenseitig aus. Beispielsweise könnte das Installationsprogramm beschließen, eine 64-Bit-Version (und nicht eine 32-Bit-Version) zu installieren, und dann könnte die 64-Bit-Version prüfen, welche Funktionen zur Laufzeit unterstützt werden, und unterschiedlichen Code für die Verwendung verschiedener Funktionen haben.
Beachten Sie auch, dass verschiedene Teile eines Betriebssystems getrennt behandelt werden können. So könnte ein Betriebssystem beispielsweise 6 verschiedene Bootloader, 4 verschiedene "HALs", 4 verschiedene Kernel und 3 verschiedene "Kernel-Module" zur Unterstützung der Virtualisierung haben, wobei einige dieser Teile möglicherweise Laufzeittests durchführen und andere nicht.
Haben Intel- und AMD-Prozessoren denselben Assembler?
Fast alle Assembler für 80x86 unterstützen fast alle Erweiterungen (von allen CPU-Herstellern - z.B. Intel, AMD, VIA, Cyrix, SiS, ...). Im Allgemeinen liegt es am Programmierer (oder Compiler) sicherzustellen, dass er nur Dinge verwendet, von denen er weiß, dass sie existieren. Einige Assembler bieten Funktionen, die dies erleichtern (z.B. bietet NASM eine CPU ... Anweisung, damit der Programmierer den Assembler anweisen kann, Fehler zu erzeugen, wenn er Anweisungen sieht, die auf der angegebenen CPU nicht unterstützt werden).
AMD und Intel verwenden denselben Befehlssatz.
Wenn Sie Windows auf einem AMD- oder Intel-Prozessor installieren, wird der Code nicht auf dem Rechner "kompiliert".
Ich erinnere mich, dass viele Leute während ihrer Studienzeit verwirrt über dieses Thema waren. Sie glauben, dass ein "Setup" bedeutet, dass der Code auf ihrem Rechner kompiliert wird. Das tut es aber nicht. Die meisten, wenn nicht sogar alle Windows-Anwendungen außerhalb des freien Bereichs, werden Ihnen als Binärdateien übergeben.
Was die Tragbarkeit angeht, so ist das nicht unbedingt zu 100 % richtig. C ist zwar sehr portabel, aber in vielen Fällen führt das Schreiben für ein bestimmtes Betriebssystem oder System dazu, dass der Code nur auf diesem System kompiliert/ausgeführt werden kann. Zum Beispiel handhaben bestimmte Unix-Maschinen Dateien und Verzeichnisse anders, so dass es nicht 100% portabel sein könnte.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
2 Stimmen
Erinnert sich noch jemand an die K5-Serie von AMD :)
0 Stimmen
Jetzt, da AMD an ARM64 arbeitet, ist diese Frage zweideutig :-)
1 Stimmen
AMD hat schon immer CPUs hergestellt, die mit Intel kompatibel sind...