Autor Thema: Funktionen Portieren  (Gelesen 6460 mal)

ReduX

  • Beiträge: 19
    • Profil anzeigen
Gespeichert
« am: 19. November 2007, 17:06 »
Hi,
Habe zwei Fragen:
1.) Das Ziel ist es ja die Funktionen alle auf seinem eigenen OS bereitzustellen, nur wie mach ich das am besten? Ich hab z.b. keinen schimmer wie ich die string Funktionen von C++ erstellen kann weil das wird in meinen Büchern einfach nicht erklärt.
2.) Ich Tue mich etwas schwer mit Assembler, ich würde lieber für alles C++ verwenden ist dies möglich?

Schönen Abend noch!
MFG ReduX

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #1 am: 19. November 2007, 17:53 »
1.) Das Ziel ist es ja die Funktionen alle auf seinem eigenen OS bereitzustellen, nur wie mach ich das am besten? Ich hab z.b. keinen schimmer wie ich die string Funktionen von C++ erstellen kann weil das wird in meinen Büchern einfach nicht erklärt.
Dann schau dir doch entweder die Implementierung einer der vielen C Standardbibliotheken (pdclib, newlib, glibc, dietlibc, ...) an (bitte auch die Lizenz beachten, falls du die übernehmen willst) oder informiere dich über die Darstellung von Zeichenketten (Stichworte: ASCII, nullterminiert). Wenn du dann noch einigermaßen mit Pointern umgehen kannst, kann du das auch selbst implementieren. Ist wirklich nicht schwer


Zitat
2.) Ich Tue mich etwas schwer mit Assembler, ich würde lieber für alles C++ verwenden ist dies möglich?
Das geht auf jeden Fall, wobei du Exceptions & RTTI (Runtime Type Information) am Anfang ausschalten solltest. Desweiteren ist für globale/statische Klassen etwas extra Aufwand von Nöten (Am besten im unserem Wiki oder im wiki von osdev.org nachsehen).
Du musst dir aber darüber im Klaren sein, dass du dann nicht einfach die Standardbibliothek von C++ hernehmen kannst (Ist ja bei C genauso).

edit: Ich kann dir nur beim g++ helfen, beim Visual oder anderen Compilern kenn ich mich leider nicht aus. Aber zu Visual C++ ist iirc was im osdev.org wiki.
« Letzte Änderung: 19. November 2007, 17:56 von bluecode »
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

ReduX

  • Beiträge: 19
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 19. November 2007, 19:04 »
Hi,
Danke für deine Antwort!
1.)Kann ich den Bootloader dann auch in C++ machen weil dafür hab ich noch niergends en Tutorial drüber gelesen.
Falls es doch in ASM sein muss, ist es schlimm wenn ich nur weiß was mov macht?

2.)Gibt es irgendwo noch Resourcen wie  Z.b. wo der Grafikspeicher(Adresse) ist etc. Weil die kenne ich nochnicht.

3.) Wo liegt der unterschied bei der 32 und 64bit entwicklung? Muss man da auf was bestimmtes achten?

MFG ReduX

blitzmaster

  • Beiträge: 77
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 19. November 2007, 20:06 »
Hi!

1.) Den Bootloader musst du afaik zu großen Teilen in ASM schreiben, ausser du benutzt GRUB. Wie das geht, dazu gibts im Magazin Teil 3 oder so einen Artikel.
2.)3.) Ich empfehle dir einmal alle Magazine (oder zumindest die ersten paar) durchzulesen, als Einführung ins OS-Programmieren.
ad 3.) Hier sind die Stichwörter Protected Mode und Long Mode wichtig. Tutorials finden sich sowohl in der Wiki als auch im Thread Magazin/Genuine Beta Leser (von Toaster) (oder so).
Auch die Linkseite in der Wiki ist ein wichtiger Anhaltspunkt, für Protected Mode ist hier das Tutorial von der FH Zwickau interessant bzw. die Seite sandpile.org.

Aber prinzipiell liegt der Unterschied in der Speicheradressierung. Da ein 32 bit Prozessor nur einen 32 Bit Daten Bus besitzt, kann er nur 4 GB RAM addressieren (im Protected Mode (~32 Bit Mode)) im 64bit Modus geht da ein bisschen mehr (mehrere Terabyte). Aber dazu kannst du in den genannten Tutorials mehr lesen.
Allerdings wirst du auch in C++ nicht um ein bisschen (inline-)Assembler herumkommen.

edit: ad 1.) In Assembler ist es empfehlenswert sich etwas mehr mit der Sprache auseinanderzusetzten  :wink: als nur zu wissen was mov macht. Wenn du aber in C++ meistens codest, wirst du sicherlich nicht so sonderlich viel können müssen, wie wenn du das ganze OS in ASM schreibst.
« Letzte Änderung: 19. November 2007, 20:09 von blitzmaster »
A / OS PM - THE operating system of the future

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #4 am: 19. November 2007, 21:35 »
3.) Wo liegt der unterschied bei der 32 und 64bit entwicklung? Muss man da auf was bestimmtes achten?
Ich würde dir erstmal empfehlen dich auf 32bit zu beschränkten, aber trotzdem soviel Code wie möglich architekturunabhängig zu halten. Über Typedefs für zB einen uintptr_t [siehe C Standard] und je nach architektur definierten uint8_t uint16_t, uint32_t, uint64_t bekommt man sowas gut hin. Versuch auch vor allem das Interface architekturunabhängig zu gestalten.
Ich fand es ziemlich schwierig eine 64Bit gcc toolchain zu benutzen. Bis ich da raushatte welche Flags ich zum kompilieren brauch, wie das Linkerscript sein sollte, etc... das hat ganz schön lange gedauert. Im Gegensatz dazu war mein Kernel (und natürlich auch der userspace) sehr schnell portiert (Vorausgesetzt man kann mit den Intel-Manuals was anfangen, denn dazu gibt es afaik nicht so wirklich Tutorials). Kannst dir ja mal mein OS anschauen. Link ist in der Signatur.

Zitat
edit: ad 1.) In Assembler ist es empfehlenswert sich etwas mehr mit der Sprache auseinanderzusetzten  :wink: als nur zu wissen was mov macht.
Assembler einigermaßen zu können ist auf jeden Fall wichtig. Aber ich denke das lernt man mit der Zeit dann auch.

Zitat
Wenn du aber in C++ meistens codest, wirst du sicherlich nicht so sonderlich viel können müssen, wie wenn du das ganze OS in ASM schreibst.
Ich würde mal behaupten, dass man sich in einer höheren Sprache mehr Gedanken über Design, Portabilität, etc. macht als über die konkrete Implementation. Und m.E. steckt da einiges mehr dahinter. Das ist meine persönliche Meinung.
« Letzte Änderung: 19. November 2007, 21:36 von bluecode »
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

blitzmaster

  • Beiträge: 77
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 20. November 2007, 16:56 »
Zitat
Wenn du aber in C++ meistens codest, wirst du sicherlich nicht so sonderlich viel können müssen, wie wenn du das ganze OS in ASM schreibst.
Ich würde mal behaupten, dass man sich in einer höheren Sprache mehr Gedanken über Design, Portabilität, etc. macht als über die konkrete Implementation. Und m.E. steckt da einiges mehr dahinter. Das ist meine persönliche Meinung.
Ich meinte das ja auch auf ASM bezogen - wenn man in c++ codet muss man nicht so sattelfest in ASM sein  :wink:
A / OS PM - THE operating system of the future

ReduX

  • Beiträge: 19
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 20. November 2007, 17:53 »
Hi,
Wegen ASM kennt da jemand ein gutes Tutorial für NASM?
Weil in google find ich fast immer nur TASM und wenns mal mit NASM ist dann nur mit Win32 Systemprogrammierung. Ich will ein Tut ohne systemprogrammierung wos halt nur um OS dev geht.

MFG ReduX

Korona

  • Beiträge: 94
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 20. November 2007, 22:02 »
Imho ist x86 Assembler nicht besonders kompliziert. Es ist kompliziert ein "ganzes Programm" darin zu schreiben, aber die Instruktionen sind nicht besonders schwer zu verstehen. Du musst wissen, welche Register du zur Verfügung hast, welche Instruktionen es gibt und wie du auf die Hardware oder auf Betriebssystem/BIOS Funktionen zugreifen kannst.

An Registern wären da die GPRs (General Purpose Registers) EAX, EBX, ECX, EDX, ESI und EDI zu nennen, welche wie der Name schon sagt "normale" Daten (Integer, jedoch keine Fließkommazahlen oder spezielle Flags) enthalten. Sie werden durch Instruktionen wie MOV, ADD, SUB etc. manipuliert. Die meisten Instruktionen können neben Registern auch auf Speicheraddressen in der Form [basis + index * scale + disp] zugreifen, wobei basis und index GPRs sind, scale entweder 0, 1, 2 oder 4 ist und disp eine Integerkonstante ist.

Bespiel:
mov eax, [ebx + ecx * 4 + 1024]

Hier wird zuerst ebx + ecx * 4 + 1024 berechnet und der 32 Bit Wert der bei dieser Addresse steht in eax geschrieben. Die [ ] markieren in NASM Speicherzugriffe. Da wir im 32 Bit Protected Mode sind manipuliert die Instruktion standardmässig 32 Bit Daten.

Um auf die Hardware zuzugreifen werden die Instruktionen "IN" bzw. "OUT" benutzt. Manche Hardwarekomponenten lassen sich auch über bestimmte Speicherbereiche direkt ansprechen. (Beispiel: Der Framebuffer der VGA Karte im Textmodus liegt bei Speicheraddresse 0xB8000. Das OS kann einfach mit "mov [0xB8000], irgentwas" auf die VGA Karte zugreifen.

Das BIOS wirst du im Realmode auf jeden Fall brauchen, auch wenn du so schnell wie möglich in den PM (Protected Mode) schalten möchtest (weil du nur dort vernünftig mit C++ arbeiten kannst und genügend Speicher zur Verfügung hast). Verwende GRUB als Bootloader um unnötige Assemblerprogrammierung zu umgehen. Falls du deinen Bootloader dennoch selber schreiben möchtest, musst du auf BIOS Funktionen zurückgreifen. Sie werden fast immer über Interrupts aufgerufen. (=> "INT" Instruktion)

Ansonsten solltest du dir einfach mal einen kleinen C/C++ Kernel ansehen, der bereits Interrupts und Schreiben von Buchstaben auf den Screen unterstützt. Ich habe meine Assembler Grundlagen hauptsächlich durch das Lesen von Beispielcode erlernt. Wenn du in C/C++ schreibst wirst du Assembler nur für die Kommunikation mit der Hardware und für einige Funktionenstubs brauchen, die spezielle Prolog und Epilog Sequenzen haben müssen. (Interrupthandler müssen mit IRET statt normalem RET zum Caller zurückkehren, außerdem müssen sie oft auch alle Register sichern, damit der Caller nicht eine veränderte Situation vorfindet etc. für fast alles andere kommst du mit einigen Zeilen Inlineassembler in deinem Code aus.)

Wenn du wirklich ein ASM Tutorial brauchst, kannst du dir das hier ansehen:
http://maven.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html

Eine Referenz aller BIOS-Interrupts gibts hier:
http://www.ctyme.com/intr/int.htm

Das NASM Manual weiß alles über die Syntax von NASM und enthält sogar eine Instruction-Referenz:
http://alien.dowling.edu/~rohit/nasmdoc0.html

Ansonsten steht alles wissenswerte in den Intel und AMD Docs, für die ich aber gerade keinen Link habe.

 

Einloggen