Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: Programm Noob am 03. October 2010, 22:55
-
Moin
Wie ihr ja wisst programmiere ich einen Bootloader. Nun hab ich mir überlegt, um solche kleinenFunktionen wie LBA2CHS zu schreiben, wäre die FPU ne nette Hilfe. Nun aber die Frage, kann Ich die FPU im Real Mode überhaupt benutzen und kann ich die einfach so nutzen oder muss ich die FPU vorher aktivieren
PNoob?
-
Du musst die immer vorher aktivieren, aber benutzen kannst du sie im Real wie im Protected Mode (sie ist schließlich aus Softwaresicht ein Coprozessor und hat wenig mit der CPU an sich zu tun).
(LBA2CHS sollte imho übrigens ohne FPU besser gehen, aber ist ja deine Sache)
-
XanClic: Ich weiß das LBA2CHS auch ohne FPU geht. Aber ich glaube es ist mit FPU schneller.
PNoob
-
"floppy: read from cyl=42, head=1, sec=8.999999999" :-D
Probier's aus und zeig uns die Ergebnisse. Ich würde tippen, es ist mit FPU langsamer.
-
Wird das hier der nächste Contest "Wer bekommt den schnellsten LBA2CHS 16 Bit Code hin" ;)
Aktivieren der FPU ist finit oder?
PNoob
-
Ich bin ja immer ein Freund von solchen Ideen, aber ich würde sie nicht mit Geschwindigkeit begründen. Deswegen stellt sich mir die Frage, wie du zu der Annahme kommst, dass das schneller ist. Was da aus meiner Sicht dagegen spricht: Ich kann mir schwer vorstellen, dass die Division in der FPU schneller ist (da komplexer), ich glaube der Overhead für den Transfer der Eingaben in bzw. Ergebnisse aus der FPU wird dominieren (geht da nicht alles über den Speicher?) und der Code dafür ist relativ komplex.
Wenn du dich tatsächlich irgendwann mal ernsthaft mit FPU-Programmierung beschäftigen willst, dann kannst du vielleicht was mit Kapitel 14 von The Art of Assembly Language Programming anfangen.
-
Zumal du in einem Bootloader auf geringe Codegröße (und wenig Abhängigkeiten) achten solltest. Naja, FPU-freie CPUs gibt es ja kaum noch.
Aber LBA in CHS umrechnen ist Ganzzahlarithmetik vom Feinsten, da ist die FPU total sinnfrei. Ich empfehle dir, nicht jedes Werkzeug zu benutzen, wenn auch der einfache Hammer reicht. Du musst für den Nagel keine Bohrmaschine ranschaffen... und auch Dübel sind da irgendwie fehl am Platze.
Gruß,
ein dir viel Erfolg wünschender
Sebastian
-
Also allein dadurch, das ich den gesamten BootLoader, der sogar schon einen Namen hat, in Assembler schreibe sollte sich die Code größe weit unter dem von einem Vergleichbarem, in C geschriebenem Boot Loader liegen.
PNoob
-
Hallo,
... in Assembler schreibe sollte sich die Code größe weit unter dem von einem Vergleichbarem, in C geschriebenem Boot Loader liegen.
Glaubst Du das wirklich? Du scheinst noch Compiler aus dem vorvorletztem Jahrzehnt zu benutzen.
Ein LBA2CHS sollte man übrigens definitiv nicht per FPU umsetzen, also ich würde meine Dateisystemtreiber nicht resistent gegen Rundungsfehler machen wollen. ;)
Grüße
Erik
-
Also allein dadurch, das ich den gesamten BootLoader, der sogar schon einen Namen hat, in Assembler schreibe sollte sich die Code größe weit unter dem von einem Vergleichbarem, in C geschriebenem Boot Loader liegen.
Hast du deine Lektion aus dem PIC-Initialisierungsbeispiel nicht gelernt? Ich fasse die Ergebnisse nochmal zusammen.
Die naive Variante:
- Dein handgeschriebener Assemblercode: 48 Bytes
- gcc -fomit-frame-pointer: 39 Bytes
Optimiert durch Code umstellen:
- Dein handgeschriebener Assemblercode: 38 Bytes
- gcc -fomit-frame-pointer: 35 Bytes
Mit viel Überlegen (und zwar nicht von dir, sondern von XanClic):
Fazit: Assemblercode selberschreiben lohnt sich maximal für den Spaß, den man dabei hat. Ansonsten ist der Aufwand viel zu hoch für den geringen (oder bei deinem Assemblercode: nicht vorhandenen) Nutzen.
-
Das war ja auch nur eine Funktion. Da die Parameter beim GCC über den Stack übergeben werden, enstehen viele unnötige push und pops.
Die unveröffentlichte Version1 meines BL's s war nichtmal ein achtes von dem was Grub auf die Diskette bringt, und das einzigste was fehlte war das laden von multiboot modulen.
PNoob
-
Hallo,
Da die Parameter beim GCC über den Stack übergeben werden
Wer sagt denn sowas? Dem kann man ganz einfach mit der richtigen Calling-Convention entgegen wirken. Außerdem beachtet der gcc bei statischen Funktionen gar keine Calling-Conventions sondern optimiert so wie es eben der Code zulässt und das auf jeden Fall besser als es ein Mensch je könnte. Wenn man beim LLVM die Link-Time-Optimization benutzt kann der das sogar für alle Funktionen die nicht über unbekannte Pointer oder von Assembler-Modulen aufgerufen werden.
Ich will nicht unhöflich sein aber Du solltest erst mal lernen guten C-Code zu schreiben bevor Du versuchst Dich mit dem Compiler zu messen (keiner von uns hätte da eine ernste Chance).
und das einzigste was fehlte war das laden von multiboot modulen
Bist Du Dir da wirklich sicher?!
Grüße
Erik
-
Gcc hat mittlerweile auch Link-time Optimization. Ich glaube seit 4.5 und es ist über den Kommandozeilenparameter -flto zu bekommen. Nur der Vollständigkeit halber. Wenn man unbedingt will kann man gcc auch zwingen eine Funktion zu inlinen.
Zum Thema (Ist ja garnicht das Thema :-D ): Ich finde nicht, dass das Ziel möglichst kleinen Codes in Assembler den dazu nötigen Aufwand rechtfertigt, sind aber nur meine 2 Cent. Ich versteh schon nichtmal das Ziel... kommt es bei einem Bootloader etwa auf die Größe an, weil wir zu wenig Massen(!)speicher haben? Ich sehe ja den Zweck des Bootloaders im Laden des Kernels und das möglichst problemlos und so, dass sich der Kernelentwickler den Realmode am besten komplett sparen kann...
-
Es geht mir einerseits um den Spass, andererseits darum einen Multiboot kompatiblen Bootloader zu haben , der auch auf bitten in einen Grafikmodus schaltet und dabei sehr klein ist.
PNoob
-
Das kann GRUB legacy mit einem Patch auch. Und wenn man unbedingt will, kann man GRUB legacy auch kleiner bekommen, aber es könnte sich da als geschickter herausstellen GRUB2 zu nehmen, dass scheint sehr modular zu sein.
-
Hallo,
Gcc hat mittlerweile auch Link-time Optimization. Ich glaube seit 4.5 und es ist über den Kommandozeilenparameter -flto zu bekommen.
Stimmt, aber dafür benötigt man die Gold-Variante von ld, die sollte zwar in allen aktuellen Distris mittlerweile mit dabei sein aber für die gnu-Tool-Chain ist das trotzdem noch ein recht junges Feature (das IMHO auch nicht ganz so gut integriert ist wie beim LLVM).
Es geht mir einerseits um den Spass
Ein lohnenswertes Ziel.
andererseits darum einen Multiboot kompatiblen Bootloader zu haben , der auch auf bitten in einen Grafikmodus schaltet und dabei sehr klein ist.
Hast Du überhaupt ne Vorstellung davon was das für ein Ziel ist? Ich glaube nicht!
Und warum soll Dein Boot-Loader unbedingt klein werden? Ich würde für GRUB gerne noch 10MB mehr geben wenn er dafür noch zuverlässiger arbeiten würde.
Grüße
Erik
-
Es geht mir einerseits um den Spass, andererseits darum einen Multiboot kompatiblen Bootloader zu haben , der auch auf bitten in einen Grafikmodus schaltet und dabei sehr klein ist.
Guck dir SYSLINUX an. Die haben ein vernünftiges Interface (COMBOOT32) mit hinreichend vielen Modulen.
Als Multibootloader gibt es "mboot.c32", als Grafikmodus gibt es "vesamenu.c32". Wenn du etwas heutzutage sinnvolles tun möchtest, dann portiere lieber Syslinux auf dein eigenes Dateisystem oder beschäftige dich mit dem Kernel - der ist eh wichtiger als der Bootloader.
Ach ja, guck mal auf die Liste mit Bugs, auf die Menge an Workarounds in sowohl GRUB als auch SYSLINUX. Dann siehst du vielleicht ein, dass du nicht jeden Fehler der Vergangenheit wiederholen musst.
Grüße,
Sebastian
-
Gut ihr meint GCC macht besseren Code. Wir legen diese Diskussion über wer macht den besten Code würde ich mal sagen aus Eis. Ich programmiere den BL auch hauptsächlich aufgrund des Argumentes "Spass".
Svenska: Ich schreibe meinen BL wie gesagt hauptsächlich aus Spass. Es ist geplant irgendwann mal GRUB konkurent zu werden, aber das ist nochSehr weit hin.
Meinen Kernel werde ich dann wieder auftauen, wenn "NandOS Loader" GRUB2 Auf meinem PC ersetzt. Vorher nicht.
PNoob
-
Ohne jetzt desillusionieren zu wollen, aber damit hast du mMn dein NandOS an den Nagel gehängt.
-
Wir werden es sehen. Ich habe grob geplant, das ich nach Weihnachten den Linuxkernel booten kann und ca 2 Monate danach die Module. Und nach weiteren 3 Monaten dann chainloading meines Windows.
Ist diese Planung sehr unrealistisch?
PNoob
-
Und wann kommt dann nach deinen Plänen Multiboot dazu? Was meinst du mit Module? Die initrd für Linux?
Die Reihenfolge ist seltsam, aber wenn du meinst... Ich würde es mir mit diesem Zeitplan zutrauen (aber natürlich ohne die Workarounds, die ich in meinem Setup nicht brauche). Ob du es kannst, weiß ich nicht.
-
Multiboot ist wenn Linux geht schon drin. ELF auch.
-
Linux ohne ELF geht auch schlecht. ;)
Also erstmal Multiboot, dann Linux, dann Multibootmodule?
-
Ja also Linux erstmal nur der Kernel, und wenn das mit multiboot Modulen geht, dann sollte auch nen Vollständiges Linux gehen.
-
Dir ist schon klar, dass Linux gerade kein Multibootkernel ist?
Für Linux gibt es ein relativ einfaches Bootmodell, welches du unter /usr/src/linux/Documentation/ findest. Der Kernel nimmt dir eine ganze Menge der Arbeit ab; auf anderen Architekturen ist es naturgemäß einfacher (ARM: Das Bootprotokoll besteht irgendwie aus einer Datenstruktur im Speicher, einem Zeiger darauf in einem Register, einer Kennziffer in einem Register und einem Sprung in den Kernel.)
Das sollte mMn (Workarounds mal weggerechnet) vor Weihnachten schaffbar sein. Achso, in dem Protokoll sind natürlich initrd und cmdline mit eingerechnet. Das zu trennen fände ich nicht zielführend. ;-)
Multiboot ist eine andere Baustelle, da darfst du auch gerne 3 Monate für einplanen - der Bootloader erledigt da eine Menge der Arbeit vorneweg.
Gruß
-
Ja also Linux erstmal nur der Kernel, und wenn das mit multiboot Modulen geht, dann sollte auch nen Vollständiges Linux gehen.
Okay. Du schaffst es nicht bis Weihnachten, weil du dich erstmal eine Weile damit beschäftigen solltest, wie denn unterschiedliche Systeme eigentlich genau booten. ;)
-
Multiboot ist eine andere Baustelle, da darfst du auch gerne 3 Monate für einplanen - der Bootloader erledigt da eine Menge der Arbeit vorneweg.
Nicht wirklich. Ich weiß es nicht mehr ganz genau, aber ich glaube, die erste Multiboot-Implementierung für qemu hat nicht mehr als maximal zwei, drei Tage gedauert.
Du darfst nicht vergessen, dass ein Bootloader, der ähnlichen Umfang wie GRUB benutzen will, die meisten Funktionen schon allein für sich selber braucht. Viel mehr als die Multibootstruktur in den Speicher legen und in den Kernel springen bleibt da auch nicht mehr, wenn Linux mal läuft.
-
Hallo,
Wir werden es sehen. Ich habe grob geplant, das ich nach Weihnachten den Linuxkernel booten kann und ca 2 Monate danach die Module. Und nach weiteren 3 Monaten dann chainloading meines Windows.
Ist diese Planung sehr unrealistisch?
Es gibt hier ein paar wenige Leute denen ich das zutrauen würde (Namen nenne ich jetzt mal keine, ich selber gehöre da nicht dazu).
Ich schreib das mal ganz direkt: Dir traue ich das definitiv nicht zu. Wobei es natürlich schön wäre wenn Du mir (uns allen) das Gegenteil beweist.
Ein Boot-Loader der auf allen möglichen PCs zuverlässig arbeitet, mit allen möglichen und unmöglichen BIOS-Eigenheiten zurecht kommt und dann noch so tolle Features wie klein (das unsinnigste Deiner Ziele), GUI (nett aber nicht zwingenst erforderlich) und Multiboot bietet ist schon ein hartes Stück Arbeit. Wenn die qemu-Leute (beachte den Plural) es in ein paar Tagen hinbekommen haben eine zusätzliche Spec zu implementieren dann ist das IMHO vor allem einer sauberen und flexiblen Code-Basis zu verdanken und gerade dafür braucht man schon einiges an Erfahrung. Ich bezweifle das ein Boot-Loader die richtige Gelegenheit ist diese Erfahrung zu sammeln.
Meine ehrliche Empfehlung ist: schließe Dich einem vorhandenen Projekt an und lerne erstmal!
Grüße
Erik
-
Also ich habe im Bereich OS-DEV einiges an Erfahrung. Ich werde mein bestes geben, euch zu beweisen, das ich es kann.
PNoob
-
Wenn die qemu-Leute (beachte den Plural) es in ein paar Tagen hinbekommen haben eine zusätzliche Spec zu implementieren [...]
Ich glaube der Vergleich zwischen qemu und einem eigenen Bootloader in Bezug auf die Multiboot-Spec hinkt gewaltig, da qemu zum einen (afaik) sowieso einen elf-Loader hat und zum anderen einiges einfacher an die nötigen Infos für die Multibootstruktur rankommt. Abgesehen davon ist qemu C-Usermodecode und kein 16Bit-mit-BIOS-Frickelassemblercode.
-
Also ich habe im Bereich OS-DEV einiges an Erfahrung.
Nein.
Ich glaube der Vergleich zwischen qemu und einem eigenen Bootloader in Bezug auf die Multiboot-Spec hinkt gewaltig, da qemu zum einen (afaik) sowieso einen elf-Loader hat und zum anderen einiges einfacher an die nötigen Infos für die Multibootstruktur rankommt. Abgesehen davon ist qemu C-Usermodecode und kein 16Bit-mit-BIOS-Frickelassemblercode.
Er hinkt nicht so furchtbar gewaltig: Ein Bootloader, der schon Linux laden kann, hat auch einen ELF-Loader. Und der qemu-Multibootloader ist auch nur ein ROM, der 16-Bit-mit-BIOS-Frickelassemblercode enthält. Der Kernel und die Module bzw. initrd lädt er über eine qemu-spezifische Schnittstelle, aber beispielsweise für die Memory Map benutzt er die ganz normalen BIOS-Funktionen (e820 und so). Theoretisch ist das ein Mechanismus, der sich in richtiger Hardware nachbauen ließe.
-
Also ich habe im Bereich OS-DEV einiges an Erfahrung.
Nein.
full ack.
Er hinkt nicht so furchtbar gewaltig: Ein Bootloader, der schon Linux laden kann, hat auch einen ELF-Loader. Und der qemu-Multibootloader ist auch nur ein ROM, der 16-Bit-mit-BIOS-Frickelassemblercode enthält. Der Kernel und die Module bzw. initrd lädt er über eine qemu-spezifische Schnittstelle, aber beispielsweise für die Memory Map benutzt er die ganz normalen BIOS-Funktionen (e820 und so). Theoretisch ist das ein Mechanismus, der sich in richtiger Hardware nachbauen ließe.
Oh ok, dann habe ich den Patch falsch eingeschätzt. Ich hätte erwartet, dass das alles im qemu-Code gemacht wird, nicht in einem ROM.
-
Multiboot ist eine andere Baustelle, da darfst du auch gerne 3 Monate für einplanen - der Bootloader erledigt da eine Menge der Arbeit vorneweg.
Nicht wirklich. Ich weiß es nicht mehr ganz genau, aber ich glaube, die erste Multiboot-Implementierung für qemu hat nicht mehr als maximal zwei, drei Tage gedauert.
Das hab ich nicht geschrieben. ;-) Ich meinte, dass Programm Noob dafür 3 Monate einplanen kann. Ohne mich mit der Multibootspec jetzt tiefgründig befasst zu haben, glaube ich, dass sie schwieriger zu implementieren ist als nativer Linux-Support.
Workarounds sind wahrscheinlich das härteste von allem, das habe ich dazu noch rausgerechnet. Im Gegensatz zu Programm Noob darf Qemu sich übrigens über eine zuerlässige (oder zumindest bekannte) BIOS-Implementation freuen... das vereinfacht Multiboot extrem.
Gruß
-
Also ich habe im Bereich OS-DEV einiges an Erfahrung.
Nein.
full ack.
+1
Mal ganz ganz doof gefragt: Wer soll später eigentlich von deinem "NandOS-Loader" (sic!) Nutzen haben? Soll das lediglich ein PoC deines "Könnens" sein, möchtest du damit dein Betriebssystem NandOS laden, soll der OS-Dever an sich das benutzen oder soll das ein Generel-Purpose-Lader werden?
Ansonsten würde ich dir einfach raten, deine Ziele nicht zu hoch zu stecken. Dass du einen Bootloader/manager schreibst ist deine Sache, du lernst mit Sicherheit etwas daraus. Was du daraus lernst weiß ich zwar nicht, aber mit Sicherheit irgendwas.
Ansonsten kann ich mich leider nur der Meinung von erik anschließen: Lerne etwas. Du hast imvvvvho keine Erfahrung im OS-Dev bzw. nicht annähernd genügend (und nein, ich vergleiche dich nicht mit einem Profi wie taljeth, ich vergleiche dich mal mit jemandem wie SHyx0rmZ) und was allgemeine Programmierung und Programmkonstrukte angeht hinkt dein Wissensstand auch oft hinterher.
Nimm das Ganze aber jetzt nicht persönlich und fasse das bitte nicht als "bashing" auf, es sind halt nur gut gemeinte Ratschläge. Du steigerst deine Reputation eben nicht dadurch, dass du hier einen auf Profi machst aber eigentlich keiner bist.
Übrigens: http://tldp.org/LDP/LG/issue70/ghosh.html (http://tldp.org/LDP/LG/issue70/ghosh.html) und http://www.ibm.com/developerworks/linux/library/l-linuxboot/ (http://www.ibm.com/developerworks/linux/library/l-linuxboot/) sind gute Anlaufadressen, um sich in den Bootprozess von Linux einzuarbeiten.
-
Hi,
ich vergleiche dich mal mit jemandem wie SHyx0rmZ
Hm, ist das jetzt eine Aufwertung von Programm_Noob oder eine Abwertung von SHyx0rmZ? :-D
SCNR
Erik
-
Um es deutlich zu machen:
taljeth > ShyX0rmZ > Programm_Noob.