Thema: Seit langer Zeit...

[bscreator]

Hallo liebe OS-Coder,
nach einer langen Zeit Pause will auch ich mich wieder ins OS-Progn stürzen.
Mal ein paar kleine Fragen an euch :
1. Wenn ich einen Kernel in C schreibe, kann ich dann auch im Real-Mode verbleiben und mit 16-Bit-Code arbeiten ?(ich frag nur, weil alle OS-Beispiele mit C-Kernel in den PM gesprungen sind)

2. Wenn ich mit dem ASM-Befehl "call" meinen C-Kernel lade, an welche Stelle im Hauptspeicher wird dann mein Kernel geladen (unterhalb von 1 MB) ?
3. Wie kann ich die Adresse festlegen, an die mein C-Kernel geladen werden soll ?

Vielleicht fragt Ihr euch, warum der nicht gleich in den PM springen will sondern im RM verbleiben will.
Naja, derjenige der fliegen lernen will, muss zuerst lernen, auf beiden Beinen zu stehen, oder ? Man kann nicht mit dem fliegen anfangen.
Vielen Dank

[FreakyPenguin]

Theoretisch gesehen kann C auch im Realmode benutzt werden. Dafür musst du aber erstmal einen Compiler finden, der für 16-Bit-CPUs kompiliert. GCC kann das (im Moment noch) nicht. (Soweit ich weiss, sind aber Bestrebungen im Gange das einzubauen, wenn das wirklich der Fall sein sollte, dauert das allerdings noch ein bischen).
Hier möchte ich aber einmal mehr die obligatorische Empfehlung anbringen: Nimm Grub. Der schaltet dir automatisch in den Protected mode und unterstützt die wichtigsten Dateisysteme. Hier findest du einen Beispielkernel von mir, falls du Interesse hast.

Zu 2:
Call lädt garnichts. Wenn die CPU einen call ausführt, wird lediglich die aktuelle Adresse auf dem Stack abgelegt, damit bei einem ret wieder zurück gesprungen werden kann. Danach wird zu der angegebenen Adresse gesprungen. Wenn call mit einem Fuktionsnamen benutzt wird, wird dieser vom Linker auch in die Adresse verwandelt.

Zu 3: Wenn Wenn du einen eigenen Bootloader benutzt, ist es deine Sache den Kernel dorthin zu laden, wo du ihn haben willst. Falls du grub benutzen willst, ist es am einfachsten, dem Linker zu sagen, er soll ELF als Ausgabeformat hernehmen. Beim Linken musst du dann auch die Adresse angegeben für die der Code gelinkt werden soll. Diese Adresse wird dann auch von Grub benutzt um den Kernel zu laden.

Wie schon gesagt: Ich würde dir vom RM abraten, da dir das, was du dort lernst, im PM nicht wirklich weiterhilft. Besser gleich im PM anfangen. Soviel schwieriger sind die Grundzüge eines Kernels dort auch nicht.

[Termite]

Moin,

das der GCC keinen 8086 / 80286 unsterstütz hab ich auch grad gesehen. Es gibt aber einen Version, die unter Dos 386 läuft und für Dos 386 code erzeugen kann. http://www.delorie.com/djgpp/ ggf hilft das weiter.

Gibt es nicht auch noch eine Betriebsmodus des 386 in der zwar 32Bit addressierung verwendet wird. ( das was der GCC eigentlich will ) aber keine speicherverwaltung mit Paging, GDT, ... notwendig ist? (FLAT MODE)

gruss

[nooooooooos]

Es gibt doch irgend so ein Turbo Compiler (von borland glaub ich), welcher für 16-Bit C-Code kompiliert.

Also ich würde dir auch raten sofort zum PM zu gehen. Du verschwendest mit dem RM nur Zeit und wenn du dich daran gewöhnst, wird es dir dann natürlich schwer fallen auf den PM umzustellen.
Und die Zwischenmodi kann man sowieso rauchen. Erstens sind die nicht so gut beschrieben(Tutorials, Leute die dir dabei helfen können...), bringen keinen Vorteil im Vergleich zum PM (und sind auch nicht viel einfacher als derselbe) und ob die bei heutigen Prozessoren noch unterstützt werden weiss ich auch nicht.


Gruss
Nooooooooooos

[bluecode]

(Soweit ich weiss, sind aber Bestrebungen im Gange das einzubauen, wenn das wirklich der Fall sein sollte, dauert das allerdings noch ein bischen).

Ernsthafte Frage: Wie kommst du da drauf? Ich kanns mir einfach nicht vorstellen...

Es gibt auch noch "Bruce's C Compiler" (bcc) der 16bit Code erzeugen kann. Ansonsten schließe ich mich den anderen an, Realmode bringt nichts. Manche fangen mittlerweile sogar mit dem longmode an (zB. läuft bitmasters OS nur noch im longmode). Abgesehen davon ist grub generell eine gute Empfehlung, va. für die die kein Interesse an intensiven Assemblerkenntnissen haben.

[bitmaster]

Abgesehen davon ist grub generell eine gute Empfehlung, va. für die die kein Interesse an intensiven Assemblerkenntnissen haben.

Also ich programmiere ja mein eigenen OS-Loader (schließlich schreibe ich ja auch ein eigenes Festplatten-Dateisystem). Aber mich würde es einfach mal so interessieren, da ich weiß, dass der GRUB in der 32 Bit Version immer in den RM  zurück schaltet und über den int 13h die Sachen lädt. Macht die 64 Bit Version das auch? Ich meine, nutzt GRUB den int 13h, schaltet dann in den LM (über den PM), und dann wieder in den RM und das Ganze von vorne. Würde mich mal nur interessieren. Hat zwar den Vorteil, dass es keine Treiber benötigt wie mein OS-Loader (der sich im LM schaltet und dann über Treiber die Daten lädt) aber das rumgeschalte zurück in den RM finde ich nicht wirklich gut (beim PM kann ich das ja noch verstehen, aber beim LM). Zumal das OS dann sowieso die Treiber benötigt. Na ja, jedem das seine.

bitmaster

[FreakyPenguin]

(Soweit ich weiss, sind aber Bestrebungen im Gange das einzubauen, wenn das wirklich der Fall sein sollte, dauert das allerdings noch ein bischen).

Ernsthafte Frage: Wie kommst du da drauf? Ich kanns mir einfach nicht vorstellen...

Ich habe mich vor ein paar Tagen ein wenig durch die gcc Seiten und die Listen gekämpft. Dabei bin ich irgendwo auf der gcc-Seite auf irgend einer TODO-Liste darauf gestossen, dass der 16-Bit port ausgebaut werden soll. Auch auf der Mailingliste finden sich dazu einige Mails.

[bluecode]

Aber mich würde es einfach mal so interessieren, da ich weiß, dass der GRUB in der 32 Bit Version immer in den RM  zurück schaltet und über den int 13h die Sachen lädt. Macht die 64 Bit Version das auch?

Es gibt keine 64bit Version von grub. Zumindest nicht von Grub legacy und von grub2 gibt es noch keinen (stable) Release.

[bitmaster]

Aber mich würde es einfach mal so interessieren, da ich weiß, dass der GRUB in der 32 Bit Version immer in den RM  zurück schaltet und über den int 13h die Sachen lädt. Macht die 64 Bit Version das auch?

Es gibt keine 64bit Version von grub. Zumindest nicht von Grub legacy und von grub2 gibt es noch keinen (stable) Release.

Ja dann, dann könnte ich GRUB sowieso nicht gebrauchen.

bitmaster

[bscreator]

Also erstmal vielen Dank für die vielen Antworten. Schade, hab gedacht, dass C auch im RM funktioniert. Naja, dann werd ich wohl noch ein bisl mit Assembler rumspielen (wobei ASM-Erfahrung mit Sicherheit nicht schadet).
Was GRUB betrifft: Ich bin der Meinung, dass zu nem eigenen OS auch ein eigener Loader gehört. Klar, mehr Aufwand. Aber wo bleibt sonst der Spass?

Noch ne abschließende Frage: Kann ich im Real-Mode  Zahlen mit einer maximalen Größe von 2^32 verarbeiten (z.B. mit einem  nem selbstgebastelten  AX:DX Mischung) oder ist das nur im 32-Bit-PM möglich?

[Korona]

Du kannst die General Purpose 32Bit Register auch im Rm benutzen, die CPU kennt ein Operand Size Override Prefix (0x66) dafür. Dein Assembler sollte es automatisch einfügen, wenn du im 16 Bit Modus mit 32 Bit Registern hantierst.

[bluecode]

Hinzuzufügen wäre natürlich noch, dass man die Register nur auf einer i386+ CPU benutzen kann (wenn auch im Realmode).

Schade, hab gedacht, dass C auch im RM funktioniert.

Wie kommst du jetzt schon wieder darauf? Das hat mit der Sprache C an sich nichts zu tun. Es gibt eben nur nicht sehr viele Compiler die es unterstützen, aber es wurden in diesem Thread bereits welche aufgezählt.

Ich bin der Meinung, dass zu nem eigenen OS auch ein eigener Loader gehört. Klar, mehr Aufwand. Aber wo bleibt sonst der Spass?

Meine Erfahrung war, dass es eben keinen Spaß macht einen Bootloader/Realmodecode zu schreiben.

[bitmaster]

Ich bin der Meinung, dass zu nem eigenen OS auch ein eigener Loader gehört. Klar, mehr Aufwand. Aber wo bleibt sonst der Spass?

Meine Erfahrung war, dass es eben keinen Spaß macht einen Bootloader/Realmodecode zu schreiben.

Also meine Erfahrungen sind da ganz anders. Mir macht es spaß einen eigenen OS-Loader zu programmieren (anstatt einfach alles zu kopieren). Und RealMode-Code ist jetzt auch nicht so viel schwieriger als PM-/LM-Code. Aber das muss jeder selber wissen. Ich bin einer, der macht gerne alles am OS selber (z.B. habe ich auch einen eigenen MBR-Code).

bitmaster

[kevin]

das der GCC keinen 8086 / 80286 unsterstütz hab ich auch grad gesehen. Es gibt aber einen Version, die unter Dos 386 läuft und für Dos 386 code erzeugen kann. http://www.delorie.com/djgpp/ ggf hilft das weiter.

Das ist Protected Mode, hilft ihm also nicht weiter.