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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Unter nicht-windows Systemen gäbe es theoretisch auch noch Fat binaries. Und neben voll emulation existiert auch noch userspace emulation.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.