Thema: Systemnahe Programmierung mit C#

[P4raFox]

Servus zusammen,

blablabla, langes Intro... zur Sache: es gibt ja zahlreiche Ansätze, die C um Objektorientierung erweitern. Mir gefällt C# davon am meisten. Also meine Frage: gibt es einen Ansatz, der C# um systemnahe Elemente erweitert und von .NET unabhängig macht (direkter  Speicherzugriff, evtl. Inline-Assembler & eigene Klassenbibiliotheken (using-Direktive)), sodass es möglich ist ein OS mit C# zu schreiben?

Ich weiss, es ist eine ziemlich verrückte Idee, aber meines Erachtens eine Überlegung wert.

[Jidder]

Hi,

es ist auf jeden Fall möglich ein OS in C# zu schreiben. Es gibt zum Beispiel das Projekt Cosmos, das CIL in x86 Assembler umwandelt (Ahead-of-Time Compiler), und somit lauffähig macht. Vom Wikipedia-Artikel kannst du dich zu weiteren ähnlichen Ansätzen hangeln. Dann gibt es noch Singularity (1, 2), das eine Variante von C# verwendet und ebenfalls einen AOT-Compiler nutzt. Außerdem gibt es noch das .Net Microframework, das für den eingebetteten Bereich gedacht ist, und einen JIT verwendet.

Allen ist gemeinsam, dass sie kein richtiges Inline Assembler haben. Cosmos hat sich zwar was gebastelt ("X#"), mit dem man in einer sehr seltsam ausschauenden Syntax teilweise sowas wie Inline Assembler machen kann, aber ich glaube nicht, dass das sehr nützlich ist, und es ist vermutlich einfacher und effizienter ein paar Zeilen externen Assemblercode zu schreiben. Singularity und das .Net Microframework nutzen Assembler in externen Dateien sowie C++.

Ob direkter Speicherzugriff in den Systemen wie im unsafe-Code von C# möglich ist, weiß ich nicht. Aber Klassenbibliotheken zu schreiben sollte kein Problem sein. Die Kernbibliothek mscorlib musst du vermutlich implementieren, ansonsten kannst du das gestalten wie du willst. Die genannten Systeme haben soweit ich weiß alle keine komplette Implementierung der Bibliothen vom .Net Framework, was vermutlich auch nicht notwendig ist.

Edit: (14.08.2012) Ich bin gerade beim Aufräumen meiner Links über einen relativ kleinen .Net Interpreter gestolpert: https://github.com/chrisdunelm/DotNetAnywhere

[kevin]

C# als objektorientierte Erweiterung von C zu beschreiben ist übrigens sehr gewagt. Es hat zwar auch geschweifte Klammern, aber sonst spricht viel dafür, dass es eine völlig eigenstände Sprache ist.

[DerHartmut]

Also C# teilt mit C an und für sich gar nichts mehr außer den Buchstaben.

Wieso genau gefällt dir denn z.B. C++ nicht? Oder Object Pascal?

Ich persönlich halte es einen immensen Aufwand, erst einmal eine kompilierbare und eigenständige Umgebung in C# zu schaffen und sich dann an das eigentliche Betriebssystem zu wagen. Wenn es dir nur um die Objektorientiertheit geht bist du da mit C++ besser bestückt. Aber vielleicht ist das genau die Herausforderung die du suchst, wer weiß.

Microsoft hat in Singularity auch eine eigene Untermenge, nämlich Sing# (was wiederrum von Spec# und das wiederrum von C# abstammt) benutzt, was auch recht krude aussieht.

Möglich ist übrigens alles: Da gibt es sogar wen bei uns im Channel, der angefangen hat ein OS in Java zu schreiben - doch ein Genuss ist es ganz sicher nicht

[P4raFox]

Ich habe nie gesagt, dass mir C++ nicht gefallen würde, jedoch war C# meine erste richtige Programmiersprache und sie gefällt mir bis heute ausserordentlich gut, da sie sehr simpel aufgebaut ist. Und kommt mir bei den anderen Sprachen nicht so vor. Ausserdem schadet ein wenig rumexperimentieren ja wohl keinem; wer weiss, wenn ich wieder @home bin habt ihr vielleicht auch einen bei euch im IRC, der ein OS in C# schreibt.

[P4raFox]

Oke ich habe mir jetzt etwas zusammegesucht, vielleicht könnte einer ja mal so lieb sein und zumindestens nachdenken, ob das funktionieren würde:
In C eine DLL schreiben, welche Funktionen für direkten Speicherzugriff (kann man hier auch von DMA reden?) bereitstellt, diese in einem kleinen, Mini-Testkernel benutzt, beides mithilfe von mono zu einer exe kompilieren, den AOT-Kompiler von mono anschmeissen um eine ELF-Objektdatei zu bekommen und diese letztenendes mit ld und dem Beispiel-Loader vom Tut für Anfänger zu linken. Das sollte dann doch eigentlich funktionieren.

Ich bin nicht zu faul um das selbst zu machen, aber ich stecke im Moment noch im Urlaub fest.


Danke im Vorraus.

[kevin]

Ich bin mir fast sicher, dass das nicht so einfach geht wie sich das bei dir anhört und es noch ein paar Fallstricke gibt.

Aber wenn du es grundsätzlich mal schaffst, deinen C#-Code in eine anständige ELF-Objektdatei kompiliert zu bekommen, die selbst nichts OS-spezifisches macht, sondern nur Funktionsaufrufe in die Runtime hat, dann sollte es eigentlich funktionieren, "nur" noch eine C-Implementierung der aus der Runtime verwendeten Teile dazuzulinken.

Gibt aber nur eine Möglichkeit, das rauszufinden...

[markusb.]

C# als Erweiterung von C zu sehen ist sicherlich nicht richtig.

Es sind völlig unterschiedliche Konzepte.
Zum Beispiel hast du bei C# eine virtuelle Maschine laufen und einen JIT, der dir zur Laufzeit das ganze kompiliert.
Durch geschickte Auswertung bekommst du da einiges an Performance raus (oftmals doch recht nah an C; gleiches gilt übrigens für Java und die JavaVM).

Mir persönlich sagt C# aber auch sehr zu. Zumindest von der Syntax.
Vor allem die nicht wirkliche Plattformunanbhängigkeit stört mich.
Das ist aber VM bedingt.
von der VM her gefällt mir wiederum Java besser.
die Sprache find ich dafür aber irgendwie.. Grausam ^^

Zurück zum Thema:
Da es in einer VM läuft, müsstest du deinem Kernel eine VM verpassen.
Eine andere Möglichkeit wäre, dass du den erzeugten Assemblercode abfängst (mit Mono funktionierts. mit .Net weiß ich nicht).
Das Problem ist aber, dass du da den optimierten ASM-Code bekommst.
Wichtige Schleifenabzweigungen fehlen können,...
gerüste kannst du damit aber sicherlich schreiben.

Mit unsafe kannst du auch mit Pointer arbeiten.
Sobald du aber Dateizugriff erstatten willst, wirds schwer.
Das einzigste, was da funktionieren KÖNNTE:
Eine DLL schrieben, die quasi einen Treiber bereit stellt.
Gleichzeitig fällt dann aber das gesamte .Net Framework weg (außer du implementierst die VM vollständig).

Was also folgt: du könntest dir zusammen mit "unsafe" Assemblercode generieren lassen und den im Nachhinein bearbeiten.
Ob das nun sinnvoll ist.. ich weiß es nicht.
Da kannst du eigentlich direk mit C arbeiten.
Das sieht mit unsafe, Pointern und ohne Klassenbibliotheken genauso aus.

Mein Rat ist deshalb, dass du lieber mit C deinen Kernel programmieren solltest.

[kevin]

Es sind völlig unterschiedliche Konzepte.
Zum Beispiel hast du bei C# eine virtuelle Maschine laufen und einen JIT, der dir zur Laufzeit das ganze kompiliert.

Quatsch. C# ist eine Sprache und ob AOT (ahead of time) oder JIT kompiliert wird, hängt einzig und allein vom Compiler ab. Für einen Kernel willst du natürlich einen AOT-Compiler benutzen. Ich bin mir im Moment nicht sicher, ob Mono das kann, aber zum Beispiel für Java kann gcj nativen x86-Code produzieren.

Mir persönlich sagt C# aber auch sehr zu. Zumindest von der Syntax.
Vor allem die nicht wirkliche Plattformunanbhängigkeit stört mich.

Die Laufzeitumgebung mag plattformabhängig sein, die Sprache ist es ziemlich sicher nicht. C# hat übrigens eine sehr anständige Spec, was recht hilfreich sein kann.

Das Problem ist aber, dass du da den optimierten ASM-Code bekommst.
Wichtige Schleifenabzweigungen fehlen können,...

Einen Compiler, der korrekten Code kaputtoptimiert, kann man nicht einen korrekten Compiler für die gegebene Sprache nennen. Ich bin mir relativ sicher, dass Mono einen einigermaßen korrekten Compiler hat (obwohl ich auch schon mal ein paar kleinere Bugs gefunden hatte).

[markusb.]

Quatsch. C# ist eine Sprache und ob AOT (ahead of time) oder JIT kompiliert wird, hängt einzig und allein vom Compiler ab. Für einen Kernel willst du natürlich einen AOT-Compiler benutzen. Ich bin mir im Moment nicht sicher, ob Mono das kann, aber zum Beispiel für Java kann gcj nativen x86-Code produzieren.

Ja, Mono kann x86 Assembler ausgeben - dieser ist aber optimiert.
Das Konzept hinter den .Net Sprachen ist aber das .Net Framework bzw. die .Net VM.
Angenommen du lässt bei C# das Framework weg/kompilierst es mit einem x86-Compiler.
Weshalb dann nicht gleich C++ oder C nehmen?
Dann kitzle ich wenigstens das letzte an Performance raus und biege das Konzept nicht in irgendwelche falschen Bahnen.

Die Laufzeitumgebung mag plattformabhängig sein, die Sprache ist es ziemlich sicher nicht. C# hat übrigens eine sehr anständige Spec, was recht hilfreich sein kann.

Natürlich ist die Sprache plattformunabhängig.
Jede Sprache ist plattformunabhängig.
Theoretisch könnte sogar x86-Assembler-Code plattformunabhängig sein.
Man braucht nur den richtigen Compiler.

Leider bleibt für mich aber .Net nicht wirklich plattformunabhängig, weil sich Mono immer etwas verspätet auf neue .Net-Versionen zurückmeldet (Leider!).

Und zu GCJ: Hier ist doch ein Thema, das die Kernelprogrammierung mit GCJ zeigen soll.
Ich finde, dass hier auf biegen und brechen versucht wird mit dieser Sprache das zu schreiben.
Dafür wird C++ mitreingemurxt,...
Recht klug scheint mir das eigentlich nicht..
Klar.. Einfach mal aus Spaß probieren. Aber trotzdem.
Abgesehen davon linkt doch GCJ de libgcj dazu -> overhead und die Frage, ob diese Lib innerhalb eines Kernels überhaupt funktionsfähig ist.

Einen Compiler, der korrekten Code kaputtoptimiert, kann man nicht einen korrekten Compiler für die gegebene Sprache nennen. Ich bin mir relativ sicher, dass Mono einen einigermaßen korrekten Compiler hat (obwohl ich auch schon mal ein paar kleinere Bugs gefunden hatte).

Das sehe ich anderes. Mono/.Net versuchen eben alles unnötige aus dem Code zu streichen, dass nur das nötigste in den Speicher muss.
Meiner Meinung nach ist das quasi wie der Teil der x86 Architektur, der versucht den Code möglichst geschickt in den Cache zu laden.
Genau das passiert hier auch schon.
Ob das abstellbar ist weiß ich nicht.
Wenn aber z.b. ganze if-schleifen wegoptimiert wurden oder oder oder,
dann ist das sicherlich nicht sehr brauchbar für die Kompilerprogrammierung.

Aber jetzt mal ganz ehrlich: würdest du mit C# einen Kernel programmieren wollen?
Und vor allem: warum willst du das eigentliche Konzept so sehr verbiegen?

Ich bleib dabei: mit C# einen Kernel programmieren zu wollen ist irgendwie unsinn.
Wobei es mich rein interesse halber auch jucken würde mit Mono x86 assembler zu genererieren und mit dem zu arbeiten.
Einfach weil mir die Sprache an sich gefällt.
Aber ob dann wirklich Treiberprogrammierung möglich ist weiß ich nicht - wohl eher weniger (außer durch C-Module/dll's).

[Jidder]

Recht klug scheint mir das eigentlich nicht..
Klar.. Einfach mal aus Spaß probieren. Aber trotzdem.

Wenn man das als Kriterium nimmt, würde hier gar nix passieren. Hier werden andauernd unkluge Dinge getan. Mit der Zeit gewöhnt man sich dran.

Das sehe ich anderes. Mono/.Net versuchen eben alles unnötige aus dem Code zu streichen, dass nur das nötigste in den Speicher muss.

Ein AOT Compiler muss doch das gesamte Programm übersetzen, oder wie soll das funktionieren? Angenommen ich hab ein C#-Programm und kompilier das zu einer ausführbaren Datei. Da sind nach deiner Aussage dann Codepfade drin, die ins leere Laufen. Was passiert dann, wenn ich das Programm starte und tatsächlich es bis an so ein Ende läuft?

[markusb.]

Wenn man das als Kriterium nimmt, würde hier gar nix passieren. Hier werden andauernd unkluge Dinge getan. Mit der Zeit gewöhnt man sich dran.

Na gut. ich bin ganz neu hier.
Dann werd ich mich wohl daran gewöhnen müssen.

Ein AOT Compiler muss doch das gesamte Programm übersetzen, oder wie soll das funktionieren? Angenommen ich hab ein C#-Programm und kompilier das zu einer ausführbaren Datei. Da sind nach deiner Aussage dann Codepfade drin, die ins leere Laufen. Was passiert dann, wenn ich das Programm starte und tatsächlich es bis an so ein Ende läuft?

Ja, das tut er auch.
Die ausführbar Datei ist ja eigentlich noch gar nicht ausführbar.
Sie wird mit dem .Net Framework geöffnet und selbiges übersetzt dann zur Laufzeit den Code, der in der CIL vorliegt.

Das mit den Codepfaden, die ins leere laufen verstehe ich gerade nicht.
Die VM stellt ja gewisse Funktionen bereit.
Diese werden dann beim Übersetzungsvorgang dazugepackt/dazugelinkt.
Da aber bei einem Kernel keine dieser Funktionen bereit stehen, kannst du diese auch nicht verwenden.

Beispiel für die CIL:

Code: [Auswählen]

.assembly HalloWelt { }
.assembly extern mscorlib { }
.method public static void Main() cil managed
{
    .entrypoint
    .maxstack 1
    ldstr "Hallo Welt!"
    call void [mscorlib]System.Console::WriteLine(string)
    ret
}Quelle: http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen/Programmiersprachen#CIL
Der Verweis auf die mscorelib muss also erst ausgewertet werden.

So zumindest mein Wissen/das, was ich aus den Informationen, die ich habe, glaube

[Jidder]

Die ausführbar Datei ist ja eigentlich noch gar nicht ausführbar.
Sie wird mit dem .Net Framework geöffnet und selbiges übersetzt dann zur Laufzeit den Code, der in der CIL vorliegt.

Ich hatte jetzt gedacht, dass wir von einem Ahead-of-Time-Compiler ausgehen, also einer, der nicht nach CIL kompiliert sondern direkt nach (x86-)Maschinencode. Die Binary wäre dann ausführbar, sofern die von dir angesprochenen fehlenden Referenzen irgendwie aufgelöst wurden oder nicht vorhanden sind. Ich glaube da liegt das Missverständnis. Ich meine mit AOT-Compiler den CIL-(nach-x86-)Compiler nicht den C#-(nach-CIL-)Compiler.

Das mit den Codepfaden bezog sich auf diese Aussagen:

Das Problem ist aber, dass du da den optimierten ASM-Code bekommst.
Wichtige Schleifenabzweigungen fehlen können,...

Das sehe ich anderes. Mono/.Net versuchen eben alles unnötige aus dem Code zu streichen, dass nur das nötigste in den Speicher muss.
...
Wenn aber z.b. ganze if-schleifen wegoptimiert wurden oder oder oder,
dann ist das sicherlich nicht sehr brauchbar für die Kompilerprogrammierung.

Das klang für mich danach, als ob der Compiler den Code nicht vollständig übersetzt, weil er zum Beispiel glaubt, dass eine if-Bedingung immer unwahr ist. Ein Just-in-Time-Compiler kann so agieren, und im Falle eines Irrtums den fehlenden Code übersetzen. Aber bei einem AOT-Compiler macht das keinen Sinn, weil der immer das komplette Programm übersetzt.

[markusb.]

Ich hatte jetzt gedacht, dass wir von einem Ahead-of-Time-Compiler ausgehen, also einer, der nicht nach CIL kompiliert sondern direkt nach (x86-)Maschinencode. Die Binary wäre dann ausführbar, sofern die von dir angesprochenen fehlenden Referenzen irgendwie aufgelöst wurden oder nicht vorhanden sind. Ich glaube da liegt das Missverständnis. Ich meine mit AOT-Compiler den CIL-(nach-x86-)Compiler nicht den C#-(nach-CIL-)Compiler.

Okay okay.
Da hast du natürlich recht.

Das klang für mich danach, als ob der Compiler den Code nicht vollständig übersetzt, weil er zum Beispiel glaubt, dass eine if-Bedingung immer unwahr ist. Ein Just-in-Time-Compiler kann so agieren, und im Falle eines Irrtums den fehlenden Code übersetzen. Aber bei einem AOT-Compiler macht das keinen Sinn, weil der immer das komplette Programm übersetzt.

So war s auch gemeint. Das funktioniert eben nur bei JIT.
Bei AOT muss natürlich alles vorhanden sein.

Aber ich hol nochmal kurz etwas aus: Bisher gibt es ja quasi keinen CIL->x86 Asm/x86_64/Maschinencode kompiler, der wirklich nur die Syntax übersetzt.
Das einzige, was meines Wissens geht ist das CIL->Asm->Maschinencode von Mono ausgeben zu lassen.
Ich bin mir nicht sicher, in wie fern das nun wirklich optimierter Code ist, oder der dann ausgeführt wird (also nur noch die Übersetzung in eine datei geschrieben wird und das selbe dann in den Prozessor geht).
Da sollte ich mal nochmal guggen.

Aber nochmal einen anderen Aspekt:
C# hat ja eigentlich einen Garbage Collector. Der würde ja dann wegfallen.
Für mich gehören zu C# eigentlich auch die ganzen Klassen des Netframeworks
Eigentlich will ich ja managed Code haben -> DLLImport und unsafe sind nicht das wahre.

Was bleibt also? ein Völlig entfremdetes C#.
Sinnvoll ist das mMn immer noch nicht.
Dann greif ich doch lieber zu C.
Du mähst ja auch nicht mit der Schere den Rasen.
Gehen tut's.
Sinnvoll ist es nicht.

[XanClic]

Sinnvoll ist das mMn immer noch nicht.
Du mähst ja auch nicht mit der Schere den Rasen.
Gehen tut's.
Sinnvoll ist es nicht.

Ich finde, es ist geradezu kaputt!

„We do what we must because we can.“ sollte Motto dieses Forums werden, denke ich.

Was bleibt also?

Asche. Alles ist vergänglich, wie Staub im Wind. Aus Sternen geboren, zu Silizium gebrannt. Zerstäubt in unendliche Weiten, mit unglaublicher Gewalt zerrissen, landet es heute unter deinem Schreibtisch in deinem Computer. Nach Milliarden von Jahren, in denen ihm so sehr zugesetzt wurde, von gewaltigem Druck zu endloser Leere – da wird es jetzt das bisschen C# für OS-Dev auch noch aushalten.

[kevin]

Ja, Mono kann x86 Assembler ausgeben - dieser ist aber optimiert.

So what? Mein Kernel wird normal mit gcc -O2 kompliert, der ist dann auch optimiert. Aber wenn der Compiler was rauswirft, was gebraucht wird, dann ist der Compiler kaputt. Ganz egal, ob die Quellsprache nun C oder C# war.

Angenommen du lässt bei C# das Framework weg/kompilierst es mit einem x86-Compiler.
Weshalb dann nicht gleich C++ oder C nehmen?

Möglicherweise weil ich finde, dass C# die schönere Sprache ist? Ich habe nicht viel Ahnung von C# und benutze in der Regel C, aber ich denke, ich würde C# vielleicht eher benutzen wollen als C++.

Und zu GCJ: Hier ist doch ein Thema, das die Kernelprogrammierung mit GCJ zeigen soll.
Ich finde, dass hier auf biegen und brechen versucht wird mit dieser Sprache das zu schreiben.
Dafür wird C++ mitreingemurxt,...

Was heißt auf Biegen und Brechen? Ich fand das, was man an Runtime unbedingt braucht, eigentlich recht straightforward. Und warum soll ein bisschen C++ für die Lowlevel-Teile in einem Javakernel nicht akzeptabel sein? Ein bisschen Assembler in einem C-Kernel für die Lowlevel-Teile stört doch auch niemanden.

Abgesehen davon linkt doch GCJ de libgcj dazu -> overhead und die Frage, ob diese Lib innerhalb eines Kernels überhaupt funktionsfähig ist.

Den Linker ruf ich immer noch selber auf. Und da kommt keine fertige libgcj rein, sondern die eigene Runtime.

if-schleifen

Aber jetzt mal ganz ehrlich: würdest du mit C# einen Kernel programmieren wollen?
Und vor allem: warum willst du das eigentliche Konzept so sehr verbiegen?

Because I can?

Aber ob dann wirklich Treiberprogrammierung möglich ist weiß ich nicht - wohl eher weniger (außer durch C-Module/dll's).

An Treibern ist jetzt wirklich nichts besonderes, die kannst du ohne weiteres in C# schreiben. Oder letztens habe ich sogar einen Kernel gefunden, in dem die Treiber in JavaScript geschrieben waren. Problematisch sind eher solche Teile wie die Speicherverwaltung.

[Svenska]

Hallo,

Treiber müssen nur externe Funktionen aufrufen können, die physische Speicheradressen lesen/schreiben und I/O machen können; wenn deine Runtime das bereitstellt, ist die Programmiersprache egal.

C# hat ja eigentlich einen Garbage Collector. Der würde ja dann wegfallen. [...]
Für mich gehören zu C# eigentlich auch die ganzen Klassen des Netframeworks [...]
Eigentlich will ich ja managed Code haben -> DLLImport und unsafe sind nicht das wahre.

Trenne mal bitte die Programmiersprache von der Runtime, die haben nichts miteinander zu tun, obwohl sie gemeinsam auftreten. Da managed code nicht freistehend ist, kannst du ihn auch nicht auf direkt auf der Hardware laufen lassen. Das betrifft OS-Dev genauso wie alles andere: Die .net-Runtime enthält definitiv unmanaged code. Muss ja nicht viel sein.

Wenn du eine .net-kompatible Runtime implementierst, die komplett freistehend ist, dann könntest du auch einen Kernel schreiben, der komplett aus managed code besteht, einen garbage collector enthält und alle Klassen vom .net-Framework enthält. Die wird vermutlich aber einen Kernel benötigen, der deutlich komplexer ist als der Kernel, den du dann schreiben möchtest - darum arbeitet man mit Subsets der Runtime.

Auch die C++-Runtime implementiert man nicht vollständig, wenn man einen Kernel in C++ schreibt.

Gruß,
Svenska