Ein paar theoretische Fragen

[eightcore]

Guten Tag.

Wird eigentlich ein Programm vor oder bei der Ausführung immer neu hardwarespezifisch assembled?
Da sich ja Opcodes von CPU zu CPU ändern (oder nicht?), müsste das eigentlich sein.
Wenn ja: "Wer" macht das?

Dann noch eine weitere Frage: Wer handled eigentlich die verschiedene Prozesse und ordnet sie der CPU zu? Schon der Kernel oder?

Und noch eine:
Wenn man unter Windows ein Programm ausführt, wird dann der Programmcode direkt auf die CPU gelassen, ohne dass es noch über irgendeine Schnittstelle geht? Oder läufts immer über Schnittstellen?

Ihr seht, was mir fehlt, ist der Durchblick. Es muss nicht unbedingt erklärt werden, Links genügen. Das Problem ist, dass ich nicht weiss, wonach ich da suchen soll.

MfG | eightcore

 

[KaeTuuN]

- Generell gibt es Skripte, welche jedes mal zur Laufzeit neu kompiliert werden und Programme welche einmalig bei der Erstellung durch den Hersteller kompiliert werden.
- Die Prozesse werden durch dein Betriebssystem (OS = Operating System) einer oder mehreren CPUs zugeordnet. Genauer gesagt, wie du schon vermutet hast durch den Kernel.
- Wird ein Programm oder ein Skript gestartet, so wird dieser Code durch die entsprechenden Schnittstellen immer weiter runtergebrochen, bis er schließlich in einer maschinenlesbaren Form ist, da eine CPU nur 0 und 1 verstehen kann und kein Ahnung hat was eine Schleife ist.
Hoffe, ich konnte zumindest einen groben Überblick geben.

Mfg Kae

 

[rumbalotte]

Wird eigentlich ein Programm vor oder bei der Ausführung immer neu hardwarespezifisch assembled?

Ein herkömmliches Anwendungsprogramm, welches du installierst, kommt schon kompiliert daher
Während der Installation wird nur auf die spezielle lokale Systemumgebung & Userwünsche eingegangen

Hingegen ein Script wird zur Laufzeit kompiliert und anschließend ausgeführt.

Da sich ja Opcodes von CPU zu CPU ändern (oder nicht?), müsste das eigentlich sein.

Es gibt verschiedene Prozessorarchitekturen (z.B. x86) mit ihren jeweiligen Befehlssatz.
Dementsprechend muss nicht auf jede einzelne CPU Rücksicht genommen werden, sondern nur auf den jeweiligen Befehlssatz.

Wenn ja: "Wer" macht das?

Der Hersteller vom Programm oder der eigene Compiler / Interpreter (mit seinem eingebauten Comiler)

Dann noch eine weitere Frage: Wer handled eigentlich die verschiedene Prozesse und ordnet sie der CPU zu? Schon der Kernel oder?

Der Prozess Scheduler, welcher entweder ein eigenständiges Modul ist oder ein Teil vom Kernel, je nach Philosophie und OS Struktur

Und noch eine:
Wenn man unter Windows ein Programm ausführt, wird dann der Programmcode direkt auf die CPU gelassen, ohne dass es noch über irgendeine Schnittstelle geht? Oder läufts immer über Schnittstellen?

Immer über Schnittstellen, sog. virtuelle Geräte(treiber).
Das hat den Hintergrund, dass ein schlecht programmiertes Programm bei direktem Zugriff das ganze System abstürzen lassen kann. Bei einer Schnittstelle dazwischen kann man das meistens abfangen und entsprechend (be)handeln, ohne das das komplette System abstürzt.

Auch hier gibt es natürlich Ausnahmen, die bekannteste ist wohl DirectX: Da im speziellen für Spiele die Zugriffe über diese virtuellen Geräte zu langsam waren, wurden Kanäle erschaffen, um auf ausgesuchte Hardwarefunktionen direkt und ohne Geschwindigkeitsverlust zugreifen zu können.

 

[eightcore]

KaeTuuN: Danke für den Scheduler, der Rest ist etwas an den Fragestellungen vorbeigegangen, bzw. wusste ich das bereits.

rumbalotte: Vielen Dank. Wie ist das dann z.B. mit einem MASM-Programm? Das geht doch nicht über Treiber, oder?

 

[Sukrim]

Auch Assemblercode wird, wie jeder andere Maschinencode, vom Windows/Linux Kernel ausgeführt. Für die CPU macht es 0 Unterschied, ob der Code früher mal Assembler, Java oder eine jpg-Datei war - solange Befehle aneinandergereiht sind, die sie versteht, wird sie auch irgendwas tun.

Zu deiner vorherigen Frage:
CPUs haben gewisse Mindeststandards (z.B. den x86 Befehlssatz) - neuere CPUs haben dann diverse Erweiterungen (z.B. die AES Erweiterungen auf aktuellen Intel CPUs). Um diese Nutzen zu können, muss je anch Programmiersprache unter Umständen der Quellcode neu kompiliert werden. Machen kann das derjenige, der den Quellcode hat - auch einer der Gründe, wieso manche auf Linux schwören, da man dann oft relativ einfach beim Wechsel auf eine neuere CPU auch alle OpenSource Programme passend "aufmotzen" kann.

 

[benneq]

@Sukrim: Deine Linux Theorie stimmt sowas von gar nicht!
So ziemlich jedes Linux, dass du installieren kannst, läuft auch noch auf 10 Jahre alten Rechnern, d.h. es ignoriert auf deiner modernen CPU einfach alle Befehlssätze. Ausnahmen sind dann Programme wie z.B. VLC oder FFMPEG, die spezielle Plugins besitzen, mit denen sie zur Laufzeit nachsehen können, was die CPU alles kann. Damit können sie dann z.B. die Video-Dekodierung dann doch mittels SSE4 oder AVX beschleunigen. Das selbe trifft auf die GPU-Beschleunigung zu: Die Programme schauen zur Laufzeit, was vorhanden ist, und aktivieren es dann. Man kann es schließlich nicht fest einkompilieren und erzwingen, wenn dann jemand mit nem älteren Prozessor kommt, dann würde gar nichts mehr gehen. Der kleinste Gemeinsame Nenner ist heutzutage meist i686.
Es gibt unter den Distributionen eine Ausnahme: Gentoo. Das System enthält keine vorkompilieren Pakete, sondern bei jeder Installation wird vorher kompiliert und auf den CPU-Typ optimiert, den der Anwender gern hätte. Das dauert natürlich jeweils 10x so lange, wie einfaches Runterladen und Installieren, dafür hat man dann aber die volle Kontrolle über das System (insbesondere auch setzen von USE-Flags, etc.).

Die Compiler:
Ein normaler Compiler (z.B. GCC) nimmt den Source-Code und erstellt ein Binary daraus, mit den Optionen, die man ihm mitgibt. Zu den Optionen gehören die Befehlssätze, die er verwenden darf. Die Alternative dazu wäre ein JIT-Compiler, diese Compiler gibt es in unzähligen Varianten: Im Normalfall geht es hier um Skriptsprachen, die zur effizienteren Verarbeitung kompiliert werden. Das wird meistens dann gemacht, wenn der Rechner merkt, dass ein bestimmtes Skript ziemlich oft benutzt wird oder einen Flaschenhals darstellt. Man kann das natürlich auch so konfigurieren, dass wirklich jedes Skript compiliert wird.

Der Weg vom Code über das Betriebssystem zur CPU:
Im Endeffekt läuft der Code natürlich immer direkt auf der CPU, anders lässt er sich schließlich auch nicht ausführen. Das Betriebssystem übernimmt hier die Prozessverwaltung und Speicherverwaltung. D.h. es sagt dem Programm wie viel Speicher es benutzen darf und wo sich dieser Speicher befindet. Dabei überprüft das Betriebssystem bei jeder Speicherallozkierung, ob damit kein Speicherbereich eines anderen Programms überschrieben wird.
Das Prozessmanagement macht grob Folgendes: Das Programm bekommt u.a. eine ID und eine Priorität und wird in eine Warteschlange eingereiht. D.h. das Betriebssystem kann zum einen alle Programme überwachen und zum anderen Bestimmen, wie oft und wann und wie lange die CPU das Programm abarbeiten soll bevor zum nächsten in der Liste gewechselt wird.
Insgesamt besteht ein Betriebssystem auf einer riesigen Anzahl an Schnittstellen (ausgenommen Micro-Kernel) und JEDE Basisoperationen läuft darüber. Denn irgendwer muss ja sicherstellen, dass die Operationen erlaubt sind und dass es keine Konflikte gibt. Z.B. auch beim Zugriff auf die HDD oder sonstige Geräte.

 

[Rossie]

- Generell gibt es Skripte, welche jedes mal zur Laufzeit neu kompiliert werden und Programme welche einmalig bei der Erstellung durch den Hersteller kompiliert werden.

Gemeint sind hier wohl Skript-Sprachen, bei denen der Quelltext erst zur Laufzeit interpretiert wird. Und Programme, die mit Sprachen entwickelt werden, die durch Kompilierung den Quelltext in ausführbaren Code überführen.

Es gibt sehr wohl auch andere Ansätze, bei denen eine Kompilierung in Maschinencode erst zur Laufzeit durchgeführt wird, und dabei dann auch Plattform-Spezifika berücksichtigt werden.

 

[Sukrim]

Es gibt unter den Distributionen eine Ausnahme: Gentoo. Das System enthält keine vorkompilieren Pakete, sondern bei jeder Installation wird vorher kompiliert und auf den CPU-Typ optimiert, den der Anwender gern hätte. Das dauert natürlich jeweils 10x so lange, wie einfaches Runterladen und Installieren, dafür hat man dann aber die volle Kontrolle über das System (insbesondere auch setzen von USE-Flags, etc.).

Mit meinem Arch-Linux kann ich (wenn ich will) auch alle Pakete mit beliebigen Optimierungen neu kompilieren, auf Gentoo geht das nur so ("Pakete" dort sind nur Anleitungen wo man Code herbekommt und wie er zu kompilieren ist), auf z.B. Debian müsste man sich schon etwas mehr verrenken (http://packages.debian.org/search?keywords=apt-build), sollte aber auch klappen.

Das Ding ist - es ist unter Linux leichter möglich an Quellcode + eine Entwicklungsumgebung zu kommen, möglich ist das natürlich unter jedem OS.

 

[benneq]

Ja, klar geht es unter jedem OS. Ist aber halt kacke, wenn man sich dann ein Update für sein Paket selbst kompiliert und es dann nicht in die Paketverwaltung bekommt Dadurch kann man sich mal schnell sein komplettes System versauen.
Klar gibt's noch andere Distributionen wo es bequem geht (oder gehen soll): Nehme man sich nur mal das Gentoo-Derivat 'Sabayon'. Das nutzt den Gentoo Paket Manager. Als ich es das erste mal getestet hab, und ein System-Update machen wollte gab es nur Probleme... Ich hab inzwischen bestimmt 40 Distributionen ausprobiert und schöner als Gentoo hat's niemand gelöst

Unter Windows und OSX wirst du es aber wohl eher nicht schaffen den Kernel auf deine CPU zu optimieren oder hast du den Quellcode?

 

[Sukrim]

Von OS-X ja... http://sourceforge.net/projects/darwinsource/

 

[benneq]

Das ist aber nur die halbe Miete. Darwin ist nur ein Teil des Systems