mikrocontroller.net

Forum: Compiler & IDEs Verständgnisfrae: Compiler für Betriebssystem


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Dem Compiler wird mitgeteilt, für welche Befehlssatzvariante er 
übersetzen soll, und ggf getrennt davon, für welche Implementierung er 
optimieren soll.

von Blinky (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
-2 lesenswert
nicht lesenswert
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
von Oliver S. (oliverso)


Bewertung
2 lesenswert
nicht lesenswert
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
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von How (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke euch allen.
Das hat mir sehr geholfen ;)

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> die sind vollständig kompatibel zueinander.

Es gibt zig Befehlssatzerweiterungen und der Compiler muss wissen, 
welche Befehle er einsetzen darf.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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
von Compilerversteher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Unter nicht-windows Systemen gäbe es theoretisch auch noch Fat binaries.
Und neben voll emulation existiert auch noch userspace emulation.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.