Hallo,
ich kompiliere in der Regel immer einen eigenen Kern. Ich habe irgendwo gelesen , das der Kompiler 3.x noch nicht für den kernl 2.6.x freigegeben ist. Stimmt das , oder kann man einen Kern 2.6.x auch mit einem neuen Kompiler gcc 3.x kompilieren? Linus Torwalds hat sich schon darüber beschwert das die neuen Kompilerversionen 3.x von gcc schlechten C - Code erzeugen würden. Da der Betriebsystemkern in C programmiert ist, möchte ich hier gern mal die Experten fragen.
FrogPR 
KarstenW „Kernelkompilierung mit gcc 3.3“
Also ersma erzeugen die Compiler keine C-Code sondern übersetzen ihn. Weiterhin..hmm, seit ich den 2.6-er nehme, kompilier ich auch mitm gcc-3.3.x, gab noch nie Probleme. Ich glaub, der Compiler ist schon gut ausgereift (den gibts schon ne ganze Weile in der Version 3.3). Für Desktop-User in ner nicht-kritischen Umgebung wirds wahrscheinlich egal sein. Fakt ist jedoch, dass im gcc-3.x deutliche Verbesserungen gegenüber 2.9x gemacht wurden sind. Inwieweit die auf das Betriebssystem auswirkungen haben, weiss nicht. Wahrscheinlich nicht sonderlich, da der Kernel ja auch auf "alten" Compilern kompiliert werden können soll.
Und im bald erscheinenden stable-Debian "sarge" ist der Compiler ein 3.3.4 (weiß ich, da ich sarge auf nem Server installiert hab, der unser WG-Netzwerk versorgt). So schlecht kann er dann ja wohl nicht sein ;-)
Gruß, FrogPR
KarstenW FrogPR „Also ersma erzeugen die Compiler keine C-Code sondern übersetzen ihn....“
Ich meinte das die neuen Kompilier C - Code schlecht kompilieren würden und schlechten Binärcode erzeugen würden.
Nur bei C++ code würden die neuen Kompilerversionen besser sein.
Ich habe mich da falsch ausgedrückt.
REPI KarstenW „Ich meinte das die neuen Kompilier C - Code schlecht kompilieren würden und...“
Gibt es schlechten und guten Binärcode ?
Wichtig ist doch in erster Linie, ob der Compiler die Sourcen fehlerfrei und damit dann lauffähig übersetzt.
Ggf. versuch doch den Compile mit der Vorgänegerversion vom 3.3.
Probieren geht ja bekanntlich über studieren.
Selbst arbeite ich z.Z. mit SuSE 9.2 (Kernel 2.6.8) und habe schon mehrmals den Kernel und die Module bisher immer mit Erfolg compiliert.
Gegenüber meiner vorherigen SuSE 8.1'er Version, ist das jetzige System natürlich wieder "fetter" und damit auf meinem Duron 1,4 Ghz langsamer geworden.
KarstenW REPI „Gibt es schlechten und guten Binärcode ? Wichtig ist doch in erster Linie, ob...“
Ja , es gibt guten und schlechten Binärcode. Ich selbst bin keine Informatiker, aber ein C-Compiler soll den Binärcode z.B. für verschienene Prozessoren optimieren.
Ich kann nicht einschätzen ob der erzeugte Binärcode gut oder schlecht ist.
Jeder Prozessor hat einen erweiterten Befehlssatz gegen über dem Vorgängermodell. Ein Prozessor wird maßgeblich (soweit ich weiß) durch zwei Dinge schneller , einmal die Taktfrequenz und zum anderen durch neue Befehle gegenüber dem Vorgängermodell.
Ein neuer Befehl ersetzt eine Reihe alter Befehle. Jeder Befehl braucht eine bestimmte Anzahl von Taktzyklen bis er abgearbeitet worden ist. Wenn der Betriebsystemkern jetzt nur noch einen neuen Befehl statt einer Anzahl alter Befehle nutzt, hat er die gleiche Arbeit mit weniger Taktzyklen abgearbeitet.
Dadurch kann der Betriebsystemkern schneller werden.
Deshalb finde ich die Diskusion um Intel- und AMD-Prozessoren so unsinnig. Zuersteinmal müßte der Betriebsystemkern oder auch das Programm den erweiterten Befehlsatz des jeweiligen Prozessors nutzen, um schneller zu werden.
Windows 2000 ist für einen Pentium 1 Prozessor kompiliert worden. Wenn man einen Pentium 4 Prozessor im Rechner hat bedeutet das, das der Rechner wie mit einem Pentium 1 Prozessor läuft, nur eben mit einer höheren Taktfrequenz.
Der Compiler gcc soll eben den Binärcode für einen bestimmten Prozessor optimieren, sodas auch der erweiterte Befehlssatz des jeweiligen Prozessors genutzt werden kann.
Ich weiß eben nicht ob die neuen Compilerversionen 3.x das so gut können, deshalb meine Frage.
REPI KarstenW „Ja , es gibt guten und schlechten Binärcode. Ich selbst bin keine Informatiker,...“
Wobei man (jedenfalls bei SuSE) in der Konfigurationsdatei für den Compilelauf angeben kann, für welchen Prozessortyp der Kernel erstellt werden soll. Gehe davon aus, daß hier schon bestimmte Optimierungen einmal der verwendeten Kernelsourcen und ggf. auch der Einstellungen am Compiler selbst verwendet werden.
Je neuer der Compiler und die jeweilige Hardware, desto besser sollten sie aufeinander abgestimmt sein.
Versuch doch mal Deinen Kernel mit der Vorgängerversion vom gcc 3.3 zu compilieren. Glaube aber eher, daß, wenn es Unterschiede gibt, diese eher "akademischer" Natur sind !
FrogPR KarstenW „Ja , es gibt guten und schlechten Binärcode. Ich selbst bin keine Informatiker,...“
Nun, Linux-Kernel unterstützen sehr wohl die spezifischen erweiterten Befehlssätze der einzelnen Prozessoren (inwieweit die dads allerdings ausnutzen, weiss ich nicht). Das kannst du ja im Kernel einstellen was für einen Prozessor du hast. Während die Option "386" auf allen x86-Plattformen läuft, tun das die weiter unten angegebenen Typen nur für den jeweiligen Prozessorentyp (ich hatte mal aus Versehn ein Intel-Kernel auf nem AMD laufen lassen, das gab ne Kernel panic beim booten. Is aber auch schon ne Weile her). Und für Intel-Prozessoren soll der Intel-eigene C-Compiler, den es übrigens auch für Linux gibt (sogar umsonst) tatsächlich in bestimmten Fällen deutlich effektiveren Binärcode erstellen (gegenüber dem gcc). Ich hatte jedenfalls zumindest über den gcc-3.3 (der ja auch die Grundlage des g++ ist, der C++-Code übersetzt) nur gutes gehört. Es kommt sicher auch auf die jeweilige Situation an und es haben sich sicher Leute mit beschäftigt und irgendwo Benchmarks veröffentlicht. Und ich kann mir auch nicht vorstellen, wieso ein alter 2.95 Befehlsätze aktueller Prozessoren besser umsetzen können sollte, als ein aktueller 3.3. Macht keinen Sinn für mich, und wenn das so wäre, dann würde der gcc-3.3 sicher unter starkem Beschuß stehen, was er wie gesagt nicht tut.
Gruß, FrogPR
