Thema: FPU im Real Mode

[Programm Noob]

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?

[XanClic]

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)

[Programm Noob]

XanClic: Ich weiß das LBA2CHS auch ohne FPU geht. Aber ich glaube es ist mit FPU schneller.

PNoob

[kevin]

"floppy: read from cyl=42, head=1, sec=8.999999999"

Probier's aus und zeig uns die Ergebnisse. Ich würde tippen, es ist mit FPU langsamer.

[Programm Noob]

Wird das hier der nächste Contest "Wer bekommt den schnellsten LBA2CHS 16 Bit Code hin"

Aktivieren der FPU ist finit oder?

PNoob

[Jidder]

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.

[Svenska]

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

[Programm Noob]

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

[erik.vikinger]

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

[kevin]

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

• Handoptimiert: 28 Bytes

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.

[Programm Noob]

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

[erik.vikinger]

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

[bluecode]

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

[Programm Noob]

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

[bluecode]

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.

[erik.vikinger]

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

[Svenska]

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

[Programm Noob]

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

[Svenska]

Ohne jetzt desillusionieren zu wollen, aber damit hast du mMn dein NandOS an den Nagel gehängt.

[Programm Noob]

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