Autor Thema: OS schon wieder  (Gelesen 21792 mal)

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #20 am: 17. October 2006, 22:19 »
Jojo....so für die ersten 2 Monate sind die Grundlagen nich schlecht.

Noooooooooooos

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #21 am: 17. October 2006, 22:32 »
gut dann schau ich mal ob ich genung geld hab und wo ich des am billigsten herbekomm.
noch ne frage zu Bochs:
Ich hab mir des jetz installiert und werd dann noch des so machen wie im dem tut beschrieben aber des mit dem image auf a.floppy kopieren oder so versteh ich nicht ganz(hab mal kurz überflogen) :-)

mfg de-big-boss

hannibal

  • Host
  • Beiträge: 400
    • Profil anzeigen
    • brainsware - the rock.
Gespeichert
« Antwort #22 am: 17. October 2006, 23:18 »
Gut Ding will ja bekanntlich Weile haben. Ein OS dagegen will noch viel mehr Weile, deshalb ist das vollkommen in Ordnung, wenn man mal was nicht versteht. :)
\\o
o//
\o/

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #23 am: 18. October 2006, 08:47 »
Ich probiers dir mal trotzdem zu erklären^^:

Dein OS kommt ja zuerst mal auf eine CD und da du ja noch keinerlei Dateisystem erstellt hast, ist da Bit für Bit lose aneinandergereiht. Wenn dann der Prozessor bestimmte Bits sieht (er sucht ja immer die Bits an der Stelle im Speicher, auf welche das Register EIP zeigt) dann bedeuten diese für ihn einen Befehl und er führt ihn aus. Ein Assembler-Befehl wird vom Assembler(-Compiler) direkt in solche Bits umgewandelt. Assembler Befehle aus Worten sind nur dazu da, um sie sich besser merken zu können.
Und wenn du nun deine Bits für dein OS zu einer Datei zusammen hast, ist das eben eine IMG-Datei.
Diese kann beliebig heissen, und du kannst sie jetzt in die Bochkonfigurationsdatei anstelle von a.floppy einbinden. (Hier heisst sie nur .floppy, weil ja die Dateiendung im Grunde genommen egal ist und Bochs hier eine IMG Datei erwartet)


Noooooooooooooooos

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #24 am: 18. October 2006, 16:23 »
aso ich kann also auch os.img da rein kopieren oder?

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #25 am: 18. October 2006, 16:25 »
Ja....natürlich musst du dann diesen anderen Dateinamen in der Konfigurationsdatei eintragen.

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #26 am: 18. October 2006, 16:50 »
ja is schon klar

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #27 am: 20. October 2006, 23:27 »
also ich hab jetz mal die augaben durchgelesen und teils nur überflogen. Und jetz hab ich ne frage und zwar:
Wenn ich jetz nen Bootloader hab, kann ich dann gleich mit C weitermachen und Sachen für die ich unbedingt Assembler bruahc über Inline Assembler machen oder ist dann die Qualität nicht so hoch bzw. geht vll Geschwindigkeit verloren.

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #28 am: 21. October 2006, 10:28 »
Hmmm ja...in dieser Frage scheiden sichi die Geister.
C ist einfacher programmieren und wird mindestens genaus so schnell wie Assembler umgesetzt sagen die einen; Das Assembler gar nicht so kompliziert ist und manuell geproggt sicher schneller ist sagen die anderen.
Ich persönlich bin für Asm. Aber später mal werd ich auch auf C umsteigen. Einfach weil das einfacher zu portieren ist auf neue Techniken und ich dann nicht alles zweimal schreiben muss.

Nooooooooooooooos

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #29 am: 21. October 2006, 11:59 »
Ja gut. Ist da ein großer Leistungsunterschied?? Und die ganzen Treiber muss ich doch aufjedenfall mit ASM machen, oder?? weil die müssen doch sehr Hardware nah programmiert sein.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #30 am: 21. October 2006, 12:30 »
Ist da ein großer Leistungsunterschied?
Meiner Meinung nach nicht. Gcc/g++ erzeugt sehr effizienten Code (wenn man mit Optimierungen kompiliert). Aber ich bin kein Assemblerprofi.

Zitat
Und die ganzen Treiber muss ich doch aufjedenfall mit ASM machen, oder?? weil die müssen doch sehr Hardware nah programmiert sein.
Da reicht ein bisschen inline Assembler für inb/inw/ind/outb/outw/outd (vllt noch ne rep variante davon), aber ansonsten braucht man eigentlich nicht viel mehr. Dadurch das man diese Funktionen in C auch noch "inlinen" kann, gibt es hier schonmal keinen geschwindigkeitsverlust.

Ich verwende auch C++ in meinem Kernel/Treibern/Programmen und bin damit _sehr_ zufrieden, va. was die lesbarkeit/wartbarkeit und auch die Programmiergeschwindigkeit angeht. Mit Assembler würd ich definitiv nicht so weit sein.

siehe Signatur, falls dich mein OS interessiert :wink:
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

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #31 am: 21. October 2006, 12:34 »
Ich denke der Leistungsunterschied ist sehr gering und  das kommt auch auf den Programmierer an.
Wenn man z.b.
OR AX, 00010000b
XOR AX, 00010000b
statt einfach
AND AX| 11101111zum löschen eines bits verwendet glaube cih kaum das man damit schneller wird als C

Assembler wirst aufjeden fall brauchen, aber mit ein parr inlein procedureen wirst du auch Treiber in C schreiben können.

Edit: Da war ich wohl wieder ein mal zu lahm  :oops:
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #32 am: 21. October 2006, 12:44 »
dann lern ich jetz erst mal die Grundlagen von C. So Variablen und so. Gibts vll irgendwo ne Tabelle oder so welche Befehle man nicht verwenden kann. Weil da gibts doch zum beispiel der Befehl printf() oda so den muss man doch erst selber schreiben. Gibts da ne Tabelle?? Bis dann.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #33 am: 21. October 2006, 12:54 »
Du darfst gar keine Funktionen benutzen, die du nicht selbst geschrieben hast. Okay ist alles, was du mit C hast, wenn du keine Headerfiles einbindest, die du nicht selbst geschrieben hast. Für printf bräuchtest du zum Beispiel #include <stdio.h>, das darfst du also nicht benutzen.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #34 am: 21. October 2006, 12:59 »
Naja...eben da kann man sich streiten.
Aber ich behaupte, dass Treiber und der Kernel schon in Asm geproggt sein sollten. Ich denke das ist schneller.
Und in meinem Asm-Buch steht, dass um unter Windows ein Fenster anzuzueigen die assemblierte Asm-Datei mehr als fünfzig mal kleiner ist, als die in C geschriebene und ebenfalls kompilierte Datei.

Nooooooooooooos

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #35 am: 21. October 2006, 13:10 »
Wenn du deine Maschine gut genug kennst, um zu wissen, wie man sie schnellstmöglich programmiert, kannst du vielleicht Geschwindkeit rausholen. Ich möchte das nicht für dich beurteilen, aber ich kann mir nicht vorstellen, daß die breite Masse hier sich gut genug damit auskennt.

Aber: Mit Assembler hast du jede Freiheit, dir selbst ins Bein zu schießen, dein Assembler wird dich nicht auf mögliche Fehler hinweisen. Allein dieser Grund der geringeren Fehleranfälligkeit ist meines Erachtens Grund genug, auf eine möglichst abstrakte Hochsprache zu setzen und dafür notfalls auch auf das letzte bißchen Geschwindigkeit oder Dateigröße zu verzichten.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #36 am: 21. October 2006, 15:54 »
Ja aber wenn ich diese Funktionen nicht benutzen darf/kann, wie kann ich denn dann ein OS in C programmieren?? Ich bruache ja irgendwelche Befehle, oder?

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #37 am: 21. October 2006, 16:09 »
Du hast alles zur Verfügung, was die Sprache C eben hergibt. Also Variablen, Pointer, arithmetische und logische Ausdrücke, Kontrollstrukturen wie if oder while, die Möglichkeit eigene Funktionen zu definieren, Inline-Assembler...

Für deine Stringausgabe nimmst du also einen Pointer auf den Grafikspeicher und schreibst dort Zeichen für Zeichen deinen String rein. Das geht mit allein mit den Mitteln der Sprache C.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

de-big-boss

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #38 am: 21. October 2006, 16:29 »
achso dann kann ich also auch cout nicht benutzen oder?

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #39 am: 21. October 2006, 16:48 »
Richtig, zumindest, solange du es nicht selbst für dein OS implementiert hast.

Zumal das C++ wäre - wir reden doch von C, oder? Es spricht natürlich auch nichts gegen C++, Pascal oder viele andere Sprachen, aber es wäre vorteilhaft zu wissen, wovon wir gerade reden. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

 

Einloggen