On 17.Aug 2003 - 08:44:06, Rene Drie�el wrote:
> Am So, 2003-08-17 um 04.23 schrieb Seth:
> > Ich hab da eine Verst�ndnisfrage.
> > [...]
> > Auf einer Seite die ich hier auch gepostet habe, habe ich gelesen das es
> > Kernel-Code und, uhm, naja, nicht-Kernel-Code gibt. ;)
> >
> > Somit w�ren die Libs wiederum Kernelabh�ngig.
>
> Ich bin zwar kein Kernel Hacker - programmiere aber von Zeit zu Zeit ein
> wenig. Ich versuche es mal so zu erkl�ren wie ich es mit denke. Ein
> Compiler macht nichts anderes als Quelltext in Maschinencode umzusetzen.
> Die folgende Zeile:
>
> $a = 1;
>
> w�rde also so aussehen (nur ungef�hr meine Assemblerkenntnisse sind
> schon sehr eingerostet).
>
> mov DH, Speicheraddresse von $a
> mov [DH], 2
>
> Jetzt ist es allerdings so so das es verschiedene Strategien der
> Umsetzung von Codekonstrukten gibt. Hierzu sollte man in einem Buch �ber
> Kompilerbau mal nachlesen. Durch diese Verschiedenen Strategien kommen
> bei unterschiedlichen Compilern auch unterschiedliche Bin�rdateien raus.
Nicht zwangsl�ufig. So sind z.B. die GNU C-Compiler alle miteinander
bin�r kompatibel. Das liegt denke ich auch daran, dass bei C viel mehr
international standadisiert ist als z.B. bei C++. Bei letzterem gabs
mittlerweile 3 Wechsel der sog. ABI (Application Binary Interface)
zwischen den Versionen 2.95, 3.0, 3.1 und 3.2. Welche alle zueinander
inkompatible Binaries erzeuge. Dagegen ist die ABI zwischen 3.3 und 3.2
gleich geblieben.
> Bei einem Aufruf von Funktionen gibt es ebenfalls verschiedene
> Strategien (wie die Parameter �bergeben werden - von links nach rechts,
> rechts nach links usw.).
>
> Aus diesen Gr�nden ist es wichtig das derselbe Compiler verwendet wird -
> da sonst irgendwas inkonsistent sein kann.
Ich bin mir nicht ganz sicher warum beim Bauen des NVidia-Kernel-Moduls
unbedingt derselbe Compiler benutzt werden muss. Aber z.B. der Aufruf
von Funktionen ist AFAIK beim gcc festgelegt und f�r C hat sich das
schon lange nicht mehr ge�ndert.
> Bei Bibliotheken bzw. Ausf�hrbaren Programmen ist das eine andere Sache
> (zumindest theoretisch). Hier sollte der Compiler keine Rolle spielen,
> da die Schnittstellen der Kernel vorgibt.
Doch grade da spielt er eine Rolle, da wie oben beschrieben der Compiler
das Bin�re Interface f�r Bibliotheken festlegt und Programme die eine
Bibliothek benutzen wollen m�ssen nat�rlich das Bin�rinterface
verstehen.
> Durch das ELF Format ist die
> Struktur einer ausf�hrbaren Datei ziemlich strikt vorgeschrieben. Diese
> Vorgaben kommen vom Kernel. Deswegen kann man auch keine Microsoft
> Windows EXE-Dateien unter Linux ausf�hren. Erst mit Hilfe von Wine wird
> dieses Format verstanden. Hier w�rde mich allerdings mal interessieren
> wie die Registrierung beim Linux Kernel erfolgt (ein apt-get mono reicht
> zum Beispiel aus das .NET Dateien ausgef�hrt werden k�nnen - das kann
> ja nicht �ber ein Kernelmodul gemacht werden).
Nun die machen gar nix mit dem Kernel. Es gibt im Kernel die M�glichkeit
Unterst�tzung in der Art einzubauen, dass entsprechende Programme
ausgef�hrt werden indem automatisch der passende Emulator geladen wird.
F�r den DosEMU hab ich das schonmal gesehen. Aber man braucht das
nat�rlich nicht um Dos-Programme im DosEMU ausf�hren zu k�nnen. Ebenso
ist es mit wine, wine setzt einfach nur die Windows-Systemrufe in
Linux-Systemrufe um, macht also nicht viel mehr als Parsen der Eingabe
und erzeugen einer passenden (Linux)Ausgabe. .NET l�uft wie Java v�llig
unabh�ngig vom darunterliegenden BS. Es gibt den Interpreter, der
BS-abh�ngig ist, aber die eigentlichen Programme sind dann in einer
Zwischensprache die vom Interpreter umgesetzt wird in jeweilige
Systemrufe. Deswegen installierst du mondo und der f�hrt dann die .Net
Programme aus.
Andreas
--
Welcher Unterschied, ob wir mit dem abgenommenen Hute einen Halbzirkel
beschreiben oder ihn senkrecht bis zur Brust herunternehmen.
-- Jean Paul
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
