Zum Beispiel, wenn ich eine C-Anwendung kompiliere, wird die ausgegebene Datei als binär gelesen oder interpretiert das OS dann die Kompilierung? Ist die "Maschinensprache" eine reine Binärdatei?
EDIT: Ja, alles auf einem Computer ist rein binär. Ich frage, ob der Prozessor direkt die vom Compiler ausgegebene Datei interpretiert oder verarbeitet das OS sie zuerst?
Ein kompiliertes Programm enthält normalerweise einen Header, gefolgt von den eigentlichen CPU-Anweisungen (was man "binär" nennen könnte) + verschiedenen anderen Daten.
Wenn Sie versuchen, dem Betriebssystem mitzuteilen, dass es Ihr Programm laden soll, wird der Header vom Betriebssystem gelesen und überprüft, ob die ausführbare Datei wirklich eine ausführbare Datei für dieses Betriebssystem und diese Architektur ist. I.e. damit Sie nicht versehentlich ein Linux-Programm unter Windows oder ähnlichem ausführen.
Der Header enthält auch verschiedene andere Informationen darüber, wo sich die eigentlichen CPU-Anweisungen in der exeutable-Datei befinden, wo sich Datensegmente (Text, Strings, Grafiken) usw. befinden.
Sobald das Betriebssystem froh ist, dass die ausführbare Datei so ist, wie es sein soll, lädt das Betriebssystem die verschiedenen Segmente aus der ausführbaren Datei in den Speicher und weist die CPU an, das "binäre" Codesegment zu starten. Dieser Code ist "rein" in dem Sinne, dass es sich um einen direkten CPU-Assembly-Code handelt.
Das Betriebssystem kann jedoch die CPU unterbrechen (zum Beispiel um zu einem anderen Programm zu wechseln oder das Programm einfach aus dem Speicher zu löschen usw.). Es gibt also eine Menge Dinge um dieses laufende Programm herum, und das Betriebssystem "verwaltet" es und stellt sicher, dass es sich wie ein netter Junge verhält, aber der Code selbst, wenn er läuft, führt so schnell wie möglich reine CPU Befehle aus ..ohne dass das Betriebssystem den Code dazwischen interpretieren muss.
Beachten Sie auch, dass das laufende Programm das Betriebssystem auf verschiedene Arten aufrufen kann, während es ausgeführt wird. Um beispielsweise das Betriebssystem aufzufordern, ein Fenster auf der Anzeige zu öffnen, eine Netzwerkverbindung zu öffnen, Speicher zuzuordnen usw. Alles, was tatsächlich passiert, ist, dass die CPU nur springt, um Code an einem anderen Ort auszuführen (d. H. Es springt vom Ausführen des Codes in der ausführbaren Datei zum Ausführen eines Stücks Code im OS und springt dann zurück).
Das ist es in aller Kürze. Es gibt jedoch viele andere Möglichkeiten, Programme auszuführen. Es gibt virtuelle Maschinen, interpretierte Sprachen (wie Java oder Ruby zum Beispiel) und so weiter. Und sie alle führen Programme auf verschiedene Arten von den traditionellen "reinen binären" Sprachen wie C / C ++ aus, aber hoffentlich hat Ihnen das geholfen, zu verstehen, wie es ein bisschen besser funktioniert.
Ich denke, was Sie wirklich fragen, ist, kompilierte Programme laufen auf Bare-Metal (führen sie unabhängig vom Betriebssystem aus). Die sehr kurze Antwort ist, nein. Obwohl das Programm selbst native CPU-Anweisungen ausführt, kann es vom Betriebssystem eingeschränkt und sein Verhalten gesteuert werden. Außerdem müssen während der Ladephase bestimmte externe (dll) Symbole aufgelöst werden. Schließlich beruhen die meisten Programme auf verschiedenen Abstraktionen des Betriebssystems (z. B. Speicherzugriff - das Schreiben eigener Swap-Funktionen ist äußerst schwierig und sinnlos). In diesem Sinne sind keine Binaries kein autonomer Bare-Metal-Maschinencode.
Sie sind jedoch reine Binärdateien. Alles auf einem Computer ist.
BEARBEITEN
Eine andere Möglichkeit, Ihre Frage zu interpretieren, ist: sind kompilierte Programme eigentlich native CPU-Anweisungen. Die Antwort ist ja (abgesehen von loading die Binärdatei, mit der das Betriebssystem helfen soll). Compiler geben Assemblersprache aus, in der jede Zeile genau einem CPU-Befehl entspricht. Dies ist immer noch Text. Die Assembly wird von einem Assembler zu einer tatsächlichen Binärdatei kompiliert.
Anwendungen wie diese werden im Allgemeinen in Maschinencode übersetzt, Anweisungen, die direkt vom Prozessor ausgeführt werden:
x86 ASM ist eine der häufigsten. Stellen Sie sich den Code so vor, dass er in einer sehr niedrigen Programmiersprache kompiliert wird. Es ist eine Ebene oberhalb von nur 1 und 0, die gerade entlang des Metalls gesendet werden, wenn Sie das meinen, und das OS hat immer noch die Kontrolle darüber, was ausgeführt wird. Aber ja, am Ende des Tages läuft alles auf Binär - alles auf einem PC reicht!
Ich frage mich, warum niemand das Konzept eines Linkers erwähnt hat.
Grundsätzlich ist die Ausgabe des Compilers eigentlich eine Binärdatei, aber es gibt einen Haken an diesem. Diese kompilierte Binärdatei wird oft als Objektdatei bezeichnet, die Objektcode enthält. Verwechsle dich nicht hier. Objektcode ist nichts anderes als Maschinencode oder Binärcode, wie Sie ihn nennen, sondern nur einen Teil davon. Der Compiler gibt normalerweise mehrere solche Objektdateien aus der Quelle eines einzelnen Programms aus. Im Wesentlichen enthält jede dieser Objektdateien einen Teil des vollständigen ausführbaren Maschinencodes für dieses Programm. Hier kommt der Linker ins Spiel. Er verbindet im Grunde alle diese Objektdateien zu einer vollständigen ausführbaren Datei , die der Rechner als Programm ausführen kann.
Tags und Links compiler-construction operating-system machine-language