Thema: In welcher Sprache codet ihr euren Kernel?

[Paul]

Nabend,
postet doch bitte mal in welcher Sprache ihr euren Kernel codet und warum.
(sehe gerade dass man keine Umfrage einfügen kann oO)

Ich stehe nämlich gerade vor der Frage: C oder C++..tendiere aber zu C weil es die meisten so machen und der Linux-Kernel wird soweit ich weiß auch nur in C programmiert. Bin mir jetzt nicht sicher wo es Vor- und Nachteile gibt.

MfG

[Jidder]

Ich code meinen Kernel in C, weil C++ in dem Zustand in dem sich mein Kernel befindet keinen Sinn macht. Ich sehe da kein Nutzen für OOP.

Mir fallen keine Objekte ein, die man nicht auch ohne Klassen umsetzen könnte, also wo struct's nicht reichen. Ich habe mir ein wenig den Linux-Kernel angeschaut und das Konzept wie da mit Objekten umgegangen wird hat, halte ich für ausreichend: Es gibt für viele Objekte jeweils ein struct, dass mit Zeigern auf Funktionen (z.B. für open(), read(), write(), etc.) gefüllt wird. Beim Aufrufen bekommen diese Funktionen dann immer als Parameter u.a. ihren Kontext übermittelt und arbeiten dementsprechend. Das kann man natürlich auch mit C++ (vermutlich eleganter) machen, allerdings ist die C Methode in der Hinsicht dynamischer, dass man da nicht auf starre Objekte angewiesen ist, sondern einzelne Methoden austauschen kann, ohne ein neues Objekt definieren zu müssen (also ableiten).

[SSJ7Gohan]

Ich habe einen kleinen Kernel, der nur für die Hardwareabhängigen Grundfunktionen zuständig ist. Das schließt ein:
-> Speicherverwaltung
-> Taskverwaltung
-> Laden von Modulen
-> Interruptverwaltung
-> Verwaltung der Rechte
-> Switchen in den Realmode, um BIOS Funktion wie VESA zu nutzen

Auf dieser Basis habe ich dann Treiber, die in Java geschrieben sind. Ich habe einen Java Compiler, der sich selbst AOT compilieren kann, dann als Kernelmodul geladen wird, und die Treiber dann JIT compiliert.

Ich habe ein kleines Interface, um mit Java direkt auf Speicherbereiche und IO Ports zugreifen zu können, dessen Funktionen werden jedoch vom JIT Compiler überwacht werden und so nicht genutzt werden können, um irgentwelche Systemteile zu ändern usw.

[Osbios]

Ich schreibe alles in Assembler, bzw. in fasm. Erst habe ich nasm benutzt, dann jedoch eine sehr komplexe Speicherorganisatzion für die assemblierung eingebaut, womit ich an die Grenzen vom nasm-preprozessor gestoßen bin.
Von hohen Progsprachen halte ich nicht so viel wenn es um die eigentlichen OS-Innereien geht. Aber sollte mein OS endlich Programme ausführen können, werde ich eventuell eine RTL für C oder FreePascal schreiben.

[Paul]

Danke erstmal für Eure Antworten.

@SSJ7Gohan: und worin sind diese module geschrieben? C oder C++? (oder pures Asm o.O)

[joachim_neu]

Ich bin auch mit purem ASM unterwegs...

[SSJ7Gohan]

Die Module sind entweder vom Java Compiler AOT compiliert, oder in C geschrieben. Der Kernel selbst ist auch in C geschrieben.

[nooooooooos]

Was heisst AOT und jit

[Paul]

ah, danke, das wollte ich wissen. ok, dann werde ich bei C bleiben. danke soweit

[Legend]

Was heisst AOT und jit

"Ahead Of Time" (z.B. wie gcj) und "Just In Time" (z.B. wie Sun's HotSpot VM)

@PorkChicken: Also meiner Meinung nach sind structs mit Funktionspointern drin ein sehr starkes Zeichen dafür, dass man lieber C++ benutzen sollte.  Das sieht mit C++ um einiges eleganter aus und sollte weniger fehleranfällig (gegen Schusselichkeit des Programmiers) sein.


Ich finde der einzig sinnvolle Grund der bei dieser langen C oder C++ Diskussion auf der LKML gebracht wurde war das Linux nun mal extrem viel Code in C ist und es würde ewig dauern den auf C++ umzustellen.

[Homix]

hi,
mein Kernel und die Treiber besteht komplett aus Pascal bzw. Delphi Language Code.
Dabei verwende ich aber auch keine Objekte sondern nur Strukturen, da sie für meine Zwecke vollkommen ausreichend sind und wenn man alles mit Objekte macht, würde der Speicherverbrauch nochmals ansteigen.

mfg,
stefan

[Legend]

Wieso das denn?

[kevin]

Wenn ich ab und zu mal ein bißchen was in diese Richtung mache, dann benutze ich FreePascal. Aber irgendwie bin ich nicht motiviert genug, sowas mal richtig durchzuziehen...

[Homix]

hi,
FreePascal hab ich mir auch mal angeschaut, aber wegen ein paar kleinen Inkompatibiliäten und Exceptions anstatt Fehlermeldungen vom Compiler bevorzug ich halt doch den Delphi 6 Compiler  

mfg,
stefan

[kevin]

Inkompatibilität zu Borland ist mir relativ wurscht, solange ich direkt für FP schreibe - und Exceptions statt Fehlermeldungen? Wie hast du denn das geschafft?

Aber das wirklich entscheidende Argument für mich ist, daß FPC im Gegensatz zu Delphi unter Linux läuft.

[Homix]

hi,
na ja als ich an der system.pas ein wenig manipuliert hab ,damit keine Win32-API Aufrufe ausgeführt werden, kam, sobald ich auf dynamische Arrays zugreifen wollte, eine Exception (auch bei InlineAsm,ect). Von Delphi bin ich mir es halt gewohnt, dass eine Fehlermeldung kommt, die mich aufklärt, welche Funktion fehlt oder ungültig ist  

Weisst du zufällig, ob es möglich ist, eine Win64-PE EXE (für Windows 64-Bit) zu erzeugen ? Wenn ja, wie ?

mfg,
stefan

[kevin]

na ja als ich an der system.pas ein wenig manipuliert hab ,damit keine Win32-API Aufrufe ausgeführt werden, kam, sobald ich auf dynamische Arrays zugreifen wollte, eine Exception (auch bei InlineAsm,ect). Von Delphi bin ich mir es halt gewohnt, dass eine Fehlermeldung kommt, die mich aufklärt, welche Funktion fehlt oder ungültig ist  

Ok, stimmt, daß der Compiler leicht allergisch reagiert, wenn er eine "compilerproc" nicht findet oder sowas, habe ich inzwischen auch bemerkt. Und welche das ist, verrät er auch nur, wenn er mit Debug-Schalter kompiliert worden ist...

Weisst du zufällig, ob es möglich ist, eine Win64-PE EXE (für Windows 64-Bit) zu erzeugen ? Wenn ja, wie ?

Vermutlich mit einem passenden Codegenerator. Nein, ernsthaft, keine Ahnung, habe ich noch nie probiert, ich habe nur einen 32-Bit-Prozessor.

Nachtrag: FP kann das wohl bisher nur für Linux.

[C#ris]

Ich habe ein kleines Interface, um mit Java direkt auf Speicherbereiche und IO Ports zugreifen zu können, dessen Funktionen werden jedoch vom JIT Compiler überwacht werden und so nicht genutzt werden können, um irgentwelche Systemteile zu ändern usw.

Das klingt ja sehr interessant! Hast du schon was veröffentlicht?
Vielleicht interessiert dich ja auch mein OS Projekt hier: http://www.xerxys.de
Auf unserem Microkernel (C) läuft nur eine "native" Anwendung, nämlich eine Java VM, die dann Java Anwendungen ausführt.
Wir wollten auch eine Art LowLevel Interface machen, mit dem man aus Java auf die Hardware zugreifen kann, aber darüber gibt es momentan keine Einigung

Gruß,
C#ris

[SSJ7Gohan]

Nein, ich code noch am JIT Compiler. Der Kernel ist aber schon komplett fertig. Ich habe schon einen kleinen Compiler für Java fertiggestellt, der aber nur AOT compilieren kann. Er kann eigentlich alles bis auf syncronisierte Threads compilieren. Jetzt arbeite ich an einer verbesserten Fassung des Compilers, der auch eine Optimierungen enthalten soll. Der alte Compiler benutzte den nativen Stack als Operand Stack, der neue benutzt die Register des Prozessors, um die Operandstackdaten zu speichern. Er ist ausserdem modularer aufgebaut und wird später eventuell mal .NET unterstützen können (zumindest von der groben Architektur her). Der Compiler ist selbst auch in Java geschrieben, kann sich aber selbst AOT compilieren und dann ausgeführt werden.

Ich hatte vor, alle Treiber in Java zu coden. Daher habe ich nur ein kleines Lowlevel Interface, um die Funktionen der Architektur zu nutzen. Es enthällt nur Funktionen für Speicher und IO-Port Zugriff, sowie einige Assemblerfunktionen, um manche Sachen zu optimieren. (System.arraycopy(), Umwandlung long/unsigned int usw.)

Bei mir läuft der gesammte Javacode in Ring0. Ring1 und Ring2 werden aus Kompatibilitätsgründen zu anderen Prozessoren und da es keinen wirklichen Vorteil brächte nicht genutzt. In Ring3 können immernoch Programme ausgeführt werden, die nicht in einer sicheren Sprache geschrieben sind, und ich plane, dafür noch einen POSIX Wrapper bereitzustellen. Ich nutze einen Hybrid-Kernel, der Treiber als Module sowie Prozesse ermöglicht.

Eventuell könnten wir zusammen an einem JIT Compiler coden, das würde die Arbeit erheblich vereinfachen.

[Legend]

Er ist ausserdem modularer aufgebaut und wird später eventuell mal .NET unterstützen können (zumindest von der groben Architektur her).

Ich finde dieser Punkt macht dieses Projekt durchaus etwas herausragend. Ich kenne bislang kein anderes Projekt das sich nicht bis aufs Messer auf eine VM festlegt. ^^