Nachrichten

1

Lowlevel-Coding / Re: [C] Informationen aus der BIOS Data Area auslesen

« am: 09. November 2013, 15:34 »

Wo genau scheitert es denn?

Eine Kurze Internet-Recherche liefert mir http://www.bioscentral.com/misc/bda.htm#

Dort steht "memory location 0040:0000h with a typical size of 255 bytes".
Also ein 255Bytes lange Struktur, welche bei adresse 0040:0000h beginnt.
Du musst also eine Struktur abbilden und dann einen Pointer vom Typ dieser Struktur auf die Adresse setzen.

Solltest du Probleme mit Pointern haben, dann solltest du zuerst zu einem C, C++, Assembler, Basic Buch oder einem Buch einer anderen Sprache, welche Pointer-funktion hat, greifen.

Schöne Grüße

2

Softwareentwicklung / Re: C-Programm mit OS verknüpfen

« am: 21. October 2012, 19:19 »

in deinen kernel schreibst du

Code: [Auswählen]

[EXTERN name_der_C_Methode]
call name_der_C_Methode
damit rufst du eine Methode auf, welche name_der_C_Methode heißt.
Diese implementierst du in C.

die Assemblerdatei kompilierst du am besten so:
nasm -felf -o kernel.o kernel.asm

In C machst du folgendes:

Code: [Auswählen]

void name_der_C_Methode()
{
    //rufe textausgabe funktion auf
}
ich kompiliere immer mit:
gcc -m32 -fno-builtin -fno-leading-underscore -fno-strict-aliasing -fno-stack-protector -Wall -O0 -c -g -o ausgabe.o ausgabe.c

diese beiden Sachen linkst du noch zusammen.
ld -melf_i386 -Tlinkerscript.ld -o kernel ausgabe.o kernel.o
das linkerskript musst du noch erstellen.
Das solltest du aber eigentlich schon haben, wenn du einen (multiboot) Kernel hast.

Achja: die Textausgabefunktion kannst du auch über C implementieren.

Was mir jetzt gerade noch einfällt: du müsstest in C bekannt geben, dass die Textausgabefunktion eine ASM funktion ist.

3

Softwareentwicklung / Re: Systemnahe Programmierung mit C#

« am: 14. October 2012, 19:43 »

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.

4

Softwareentwicklung / Re: Systemnahe Programmierung mit C#

« am: 14. October 2012, 17:18 »

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

5

Softwareentwicklung / Re: Systemnahe Programmierung mit C#

« am: 14. October 2012, 15:07 »

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).

6

Softwareentwicklung / Re: Systemnahe Programmierung mit C#

« am: 13. October 2012, 18:13 »

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.