Hallo Leute,
ich hätte da mal eine Anfägerfrage bezüglich Compiler und
Betriebssystem?
Ich habe das so gelernt, dass man für jeden Prozessor einen anderen
Compiler braucht wenn man Programm auf diesem ausführen will. Ist ja
auch logisch weil jeder Prozessor einen anderen Behlssatz hat(wenn auch
nur geringfügig).
Wie sieht das ganze jetzt damit aus wenn ich ein Betriebsystem am laufen
habe. Es ist ja so das wenn ich unter Windows ein Programm mit einer IDE
compiliere, dass es ja dann egal welcher Rechner, auf jedem Windows
funktioniert. Somit spielt es da anscheinend keine Rolle welcher
Prozessor unter dem Windows sitzt?
Wie funktioniert denn das? Ist da so eine art virtueller Prozessor
dazwischen für diesen der Compiler dann den Maschinencode produziert?
Und dieser ist bei jedem Windows (Sofern es die selbe windows version)
gleich?
Danke schon mal im voraus ;)
Gruß
Florian
Dem Compiler wird mitgeteilt, für welche Befehlssatzvariante er
übersetzen soll, und ggf getrennt davon, für welche Implementierung er
optimieren soll.
Hallo Florian,
das kommt immer auf das Betriebssystem an.
Windows besitzt eine sogenannte Hardwareabstraktionsschicht (Englisch
"HAL" für Hardware Abstraction Layer ->
https://de.wikipedia.org/wiki/Hardwareabstraktionsschicht).
Diese Schicht dient grob gesagt der Übersetzung zwischen der Software
und unterschiedlichen Varianten der Hardware, wie z.B. dem Prozessor.
Hat das Betriebssystem keine solche Abstraktionsschicht, muss die
Software für jeden Prozessor kompiliert werden.
Florian schrieb:> Es ist ja so das wenn ich unter Windows ein Programm mit einer IDE> compiliere, dass es ja dann egal welcher Rechner, auf jedem Windows> funktioniert.
Es gibt im Wesentlichen nur 2 verschiedene Prozessoren auf PCs die mit
Windows verkauft werden/wurden: x86 und x86_64. Und Software für
ersteres läuft sogar auch auf letzterem. Und ob AMD oder Intel
draufsteht spielt gar keine Rolle, die sind vollständig kompatibel
zueinander.
Blinky schrieb:> Windows besitzt eine sogenannte Hardwareabstraktionsschicht (Englisch> "HAL" für Hardware Abstraction Layer ->> https://de.wikipedia.org/wiki/Hardwareabstraktionsschicht).> Diese Schicht dient grob gesagt der Übersetzung zwischen der Software> und unterschiedlichen Varianten der Hardware, wie z.B. dem Prozessor.
Das ist in dem Kontext der Frage mißverständlich. Auch bei Windows
laufen User-Programme direkt auf dem Prozessor, ohne jede
Zwischenschicht. Da wird nichts zwischen Software und Prozessor
"angepasst". Was nicht passend für den vorhandenen Prozessor compiliert
wurde, läuft nicht.
Die Windows-HAL enthält hardwarespezifische Implementierungen der
hardewarenahen Betriebssystemroutinen, die dann vom Betriebsystem und
von Anwendungsprogrammen genutzt werden.
Das fertig compilierte Software auf jedem Windows-Rechner funktioniert,
lässt sich auf zwei Arten gewährleisten:
a) Das Programm nutzt nur einen Basis-Befehlsssatz, den alle Prozessoren
unterstützen.
b) Das Programm enthält mehrere Versionen des gesamten Programms oder
spezieller DLLs, und bei der Installation oder auch erst beim Start wird
die passenden ausgewählt.
Oliver
Blinky schrieb:> Hat das Betriebssystem keine solche Abstraktionsschicht, muss die> Software für jeden Prozessor kompiliert werden.
Auch mit HAL muss die Software für jeden Prozessor kompiliert werden.
Der HAL sorgt ja nicht dafür, dass ein Prozessor plötzlich Instruktionen
ausführen könnte, die er gar nicht kennt (das wäre Emulation => langsam
- obwohl es auch das gibt bzw. gab).
Der HAL startet mit dem kleinsten gemeinsamen Vielfachen an
Instruktionen der Prozessorarchitektur, auf dem er läuft und guckt dann
erst mal, worauf genau (Variationen innerhalb der Architektur).
Abhängig vom Ergebnis werden dann die Codeteile für genau diese Maschine
"scharf" gemacht. Teile für andere, unpassende Maschinen sind ab diesem
Zeitpunkt dead code und werden nicht aufgerufen.
So ist es!
Lade dir doch einmal von MS den kostenlosen Compiler runter und
compiliere mal kleine Quelldateien. Dann spiel damit ein wenig herum und
lerne welche Möglichkeiten solche Compiler besitzen. Dann wird deine
Frage automatisch beantwortet.
Bernd K. schrieb:> die sind vollständig kompatibel zueinander.
Es gibt zig Befehlssatzerweiterungen und der Compiler muss wissen,
welche Befehle er einsetzen darf.
A. K. schrieb:> Bernd K. schrieb:>> die sind vollständig kompatibel zueinander.>> Es gibt zig Befehlssatzerweiterungen und der Compiler muss wissen,> welche Befehle er einsetzen darf.
Für 0815-Zeug (also 99,9% der Software da draußen) wird einfach der
kleinste gemeinsamen Nenner gewählt, der Compiler wird Code erzeugen der
auf jedem x86-64 läuft und alle Spezialerweiterungen von einzelnen AMD
oder Intel komplett links liegen lassen.
Es sei denn Du schreibst ne Number-Crunching Library oder nen
Video-Encoder oder ne Game-Engie oder nen Betriebssystemkernel, da
könnte man sich vielleicht an ausgewählten Stellen zu solcher
Code-Akrobatik wie zur Laufzeit entscheiden welche unterschiedlich
kompilierte oder handgeklöppelte Variante der selben Funktion auf diesem
Prozessor zu nutzen ist hinreißen lassen.
Florian schrieb:> Wie sieht das ganze jetzt damit aus wenn ich ein Betriebsystem am laufen> habe. Es ist ja so das wenn ich unter Windows ein Programm mit einer IDE> compiliere, dass es ja dann egal welcher Rechner, auf jedem Windows> funktioniert.
Es gibt noch einen weiteren Aspekt: wie muss ein Anwendungsprogramm
dass, sagen wir mal in x86-Maschinenbefehle Berechnungen durchfuehrt,
die Ergebnisse an das BS weitergeben sodass sie eben
BS-&Oberflaechentypisch dem Anwender am Bildschirm gezeigt werden.
Dazu haben verschieden Laufzeitumgebungen oder BS-Anbindungen ihre
typische Konventionen: wohin mit den Daten (Register/Stack/Speicher) und
wie die BS-Funktion welche diese Daten "abholt" aufzurufen ist.
Dazu sind im wesentlichen einzubindene Biliotheken da und diese
muessen vom BS-Macher mitgeliefert werden (ggfs. an den Compilerbauer
geliefert und landen mit Kauf&Installation auf dem Rechner).
Damit weiss dann die Entwicklungsumgebung (Compiler + Linker + ...) wie
diesen Aspekt im Anwendungsprogramm zu machen ist, resp. so kann die
Entwicklungsumgebung vom Anwendungsprogramm auch Varianten fuer
"artfremde" BS erzeugen.
E.g. Enwicklungsrechner x86 mit Linux generiert Anwendungsprogramm nebst
fuer x86 Linux auch fuer x86 Windows, x86 CP/M, x86 VxWorks, usw.
(Beachte: in diesem Bsp. ist erstmal die CPU Architektur gleich).
Bernd K. schrieb:> Florian schrieb:>> Es ist ja so das wenn ich unter Windows ein Programm mit einer IDE>> compiliere, dass es ja dann egal welcher Rechner, auf jedem Windows>> funktioniert.>> Es gibt im Wesentlichen nur 2 verschiedene Prozessoren auf PCs die mit> Windows verkauft werden/wurden: x86 und x86_64. Und Software für> ersteres läuft sogar auch auf letzterem. Und ob AMD oder Intel> draufsteht spielt gar keine Rolle, die sind vollständig kompatibel> zueinander.
Aber andersherum (x86_64 Software auf 86) klappt schonmal nicht. Und
dann gibt es Windows auch noch für ARM, was wiederrum andere
Binärdateien (also Kompilate für eine andere Zielarchitektur) erfordert
(wen man nicht eine langsame Emulationsschicht verwenden will).
Ein kompiliertes Windowsprogramm läuft also höchstens auf zwei von drei
von Windows unterstützten Architekturen, im Normalfall sogar nur auf
einer.
Philipp Klaus K. schrieb:> Ein kompiliertes Windowsprogramm läuft also höchstens auf zwei von drei> von Windows unterstützten Architekturen, im Normalfall sogar nur auf> einer.
Was für ein für x86-Architekturen kompiliertes Programm nichts anders
bedeutet, als daß es auf 99% aller Windowsinstallationen läuft, und auf
dem kümmerlichen Rest laufen davon dann wiederum 99% in der Emulation.
Passt scho.
Oliver
