Eigenes OS?

Nobuo T

Erhard Henkes schrieb:

Es waere uebrigens sinnvoll, die Initialisierung des Stacks nicht unter den Tisch fallen zu lassen.

Ich hatte einen geschrieben, selbstverständlich ohne cli/sti, habe ihn aber im Tutorial gelöscht, weil es auch so lief (Didaktik ;)).
Reicht es, wenn man den Stack erst im Kernel implementiert? Im BL (bewusst primitiv gehalten, weil ansonsten immer zu GRUB geraten wird) hat der Stack m.E. noch nichts zu suchen.

Dafuer, dass er im BL "noch nichts zu suchen hat", machst du aber doch regen Gebrauch davon.
Wenn du es ganz sauber haben willst, kannst du ihn im Kern nochmal an eine ausgekluegeltere Stelle verfrachten.

Erhard Henkes

; set parameters for reading function
    ; 8-bit-wise for better overview
    mov dl,[bootdrive] ; select boot drive
    mov al,10          ; read 10 sectors
    mov ch, 0          ; cylinder = 0
    mov cl, 2          ; sector   = 2
    mov dh, 0          ; head     = 0
    mov ah, 2          ; function "read"

Das bleibt! Hier geht die Didaktik vor.
Ansonsten danke für die Tipps!
Ich habe alle Helfer bereits "namentlich" im Tutorial erwähnt.

http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Erhard Henkes

Dafuer, dass er im BL "noch nichts zu suchen hat", machst du aber doch regen Gebrauch davon.

OK, ich sehe es ein:

org 0x7C00  ; set up start address 

    ; setup a stack 
    mov ax, 0x9000  ; address of the stack
    mov ss, ax      ; SS = 0x9000 
    xor sp, sp      ; SP = 0x0000 

    ; start
    mov [bootdrive], dl ; boot drive from DL
    call load_kernel    ; load kernel

    ; jump to kernel
    jmp 0x1000:0x0000   ; address of kernel

mit einem "OS" hat dieses x86er-bootloader gefrickel noch nicht viel zu tun. wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.

Nobuo T

Im Prinzip richtig. Nur duerfte es sehr schwierig werden, dieses weite, eher theorielastige Themengebiet geschickt mit Erhards praktisch ausgerichteter Didaktik unter einen Hut zu bringen.

Erhard Henkes schrieb:

Das bleibt! Hier geht die Didaktik vor.

Ok, aber vielleicht kann ich dich noch ueberzeugen, der Sache einen kleinen Kommentar zur Effizienz beizufuegen. Ich kriege jedes Mal einen Krampf, wenn ich sowas sehe (zuletzt sogar in einem kommerziellen BL).

Ins Kapitel "4.5.1 Bootloader" passt ev. noch einiges zur relativen (segmentierten) Schreibweise von Adressen:

Relative Adresse -> Segment:Offset
Absolute Adresse -> (Segment * 0x10) + Offset

org 0x7C00 ; set up start address  

; setup a stack
mov ax, 0x9000  ; address of the stack
mov ss, ax      ; SS = 0x9000
xor sp, sp      ; SP = 0x0000 
(...)
; jump to kernel
jmp 0x1000:0x0000   ; address of kernel

Das Programm startet bei 0x7C00, legt einen Stack an bei 0x9000, lädt den Kernel nach 0x1000 und springt dorthin.

Das Programm startet relativ bei 0000:7c00, absolut bei (00000x10)+7c00 = 0x7c00.
Aber der Stack liegt relativ bei 9000:0000, absolut bei (90000x10)+0 = 0x90000.
Der Kernel liegt somit absolut bei 0x10000, weshalb der Bootloader alleine locker (0x10000 - 0x7c00 = 0x8400) über 33 KB groß sein kann.
Prinzipiell eine nicht akzeptable Verschwendung von (einstmals) wertvollen Speicherplatz.
Aber das sollte vorerst keine Rolle spielen. Didaktik geht vor!

Erhard Henkes

... weshalb der Bootloader alleine locker (0x10000 - 0x7c00 = 0x8400) über 33 KB groß sein kann.

Guter Hinweis! Ich erkläre jetzt mal, warum mir die Didaktik und ein umfassendes Verständnis wichtiger ist als ein schnelles Vorwärtsschreiten, bei dem man viele verliert und wichtige Details auf der Strecke bleiben.

So findet man dies nun im Tutorial:

0h *  16^4 + 8h * 16^3 + 4h * 16^2 + 0h * 16^1 + 0h * 16^0  =
0  * 65536 + 8  * 4096 + 4  * 256  + 0  * 16   + 0  * 1     =
             32768     + 1024                               =  33792

33792 Byte / 1024 = 33 KByte

Korrekt ist also:
Der Bootloader darf höchstens 33 KB groß sein.

Würdet ihr den Kernel auf 7E00h setzen? Dann passt kein Byte mehr dazwischen.
Eigentlich könnte man sogar die beiden Boot-Signatur-Bytes überschreiben?
Also 7DFEh als Minimum? Didaktisch interessante Frage, finde ich.

Experiment mit 7DFEh: Absturz (bleibt "hängen", lädt keinen Kernel)
Experiment mit 7E00h: läuft ständig im Kreis (Bootloader Message erscheint und wird wieder gelöscht)
Also: Wieviel Abstand wird genau benötigt und warum?

Ins Kapitel "4.5.1 Bootloader" passt ev. noch einiges zur relativen (segmentierten) Schreibweise von Adressen

Ich habe ein Kap. 4.5.4 "Background-Wissen: Speicheradressierung im Real Mode (RM)" aufgenommen und in 4.5.1 darauf verwiesen:

Das Programm startet bei 07C00h, legt einen Stack an bei 90000h, lädt den Kernel nach 10000h und springt dorthin.
Adressierung im Real Mode siehe Abschnitt 4.5.4

Erhard Henkes

vielleicht kann ich dich noch ueberzeugen, der Sache einen kleinen Kommentar zur Effizienz beizufuegen. Ich kriege jedes Mal einen Krampf, wenn ich sowas sehe

@Nobuo T:
Das möchte ich nicht, dass Dir schlecht wird bei dem Code.
Wir brauchen Dich noch zum Überprüfen/Optimieren.
Ich habe auf Deinen Wunsch hin folgende Passage ergänzt:

Hinweis: Die Verwendung des High und Low Byte eines Registers in Verbindung mit dem Befehl mov, wenn genau so gut das gesamte 16-Bit-Register mit einem Befehl bedient werden könnte, ist eine Verschwendung von Prozessortakten! Dies geschieht in obigem Fall nur der besseren Übersicht wegen. Performanter Programmierstil ist dies nicht.

Also anstelle

mov al,10 (mov al, 0x0A)
mov ah, 2

verwendet man performant

mov ax, 0x020A

Nun wollte ich schreiben, wieviele Takte man oben und unten benötigt, habe aber keine Übersichtslisten gefunden. Kennt sich da jemand aus? Link?

Erhard Henkes

Muss man eigentlich auch auf das Little Endian-Format bei Intel Prozessoren ("Lowest Byte first") eingehen? Ich denke ja, denn bereits, wenn man

times 510-($-$$) db 0
dw 0xAA55

schreiben wollte, anstelle

times 510-($-$$) db 0
db 0x55
db 0xAA

Dann muss man die veränderte Reihenfolge erklären. Im Hexeditor sieht man ja auch:
aus dw 0xAA55 wird im Speicher 55AA

Zur Vermeidung habe ich zwei Mal db verwendet.

wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.

Hoffentlich bist Du noch jung. Das kann noch etwas dauern. Nein, im Ernst. Ich möchte jeden Schritt genau ausloten, niemand verlieren.

Erhard Henkes schrieb:

Muss man eigentlich auch auf das Little Endian-Format bei Intel Prozessoren ("Lowest Byte first") eingehen? Ich denke ja

das solltest du unbedingt tun, mit begründung, warum die x86'er sowas machen. und dann nicht nur für 2-byte werte.

Erhard Henkes schrieb:

wann geht's denn endlich los mit multitasking, betriebsmittelverwaltung, hal, etc.

Hoffentlich bist Du noch jung. Das kann noch etwas dauern.

hoffentlich bist du noch jung. bei den themen kannste dir 'nen wolf schreiben.

Nobuo T

Also wenn schon, denn schon:

Hinweis: Die Verwendung des High und Low Byte eines Registers in Verbindung mit dem Befehl mov, wenn genau so gut das gesamte 16-Bit-Register mit einem Befehl bedient werden könnte, ist eine Verschwendung von Speicherplatz und Prozessortakten (in diesem Fall 1 Byte und max. z.B. auf einem 486 1 Takt zusätzlich)! Dies geschieht in obigem Fall nur der besseren Übersicht wegen. Performanter Programmierstil ist dies nicht.

Also anstelle

mov al,10 (mov al, 0x0A)
mov ah, 2

verwendet man performant

mov ax, 0x020A

Erhard Henkes schrieb:

Nun wollte ich schreiben, wieviele Takte man oben und unten benötigt, habe aber keine Übersichtslisten gefunden. Kennt sich da jemand aus? Link?

Ist alles ziemlich undurchsichtig. Quellen waeren Docs aktueller CPU von den Herstellern. Wie aber bereits erwaehnt, braucht schon der 486 max. 1 Takt fuer so ein mov - auf neueren CPU werden das vermutlich nicht mehr sein.
Zumindest AMDs fruehere 64Bitter liessen sich von sowas AFAIR auch gern mal die Pipeline durcheinander bringen, also wahrscheinlich dann auch 2 Takte.

Erhard Henkes

Also wenn schon, denn schon:

Was meinst Du damit?

Nobuo T

Ich habe mir erlaubt, deinen Text hauptsaechlich um die Erwaehnung des zusaetzlichen Speicherplatzverbrauchs zu erweitern (was in einem BL wichtiger sein duerfte als 1 verpulverter CPU-Takt), falls das nicht aufgefallen sein sollte...

abc.w

Bezüglich Takte gibt es hier http://www.agner.org/optimize/ unter "4. Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel and AMD CPU's" eine schöne Übersicht über die ganzen Befehle und deren Takte, uOps und was weiss der Teufel noch was... falls es jemand genauer wissen möchte.

Erhard Henkes

Ich habe mir erlaubt, deinen Text hauptsaechlich um die Erwaehnung des zusaetzlichen Speicherplatzverbrauchs zu erweitern (was in einem BL wichtiger sein duerfte als 1 verpulverter CPU-Takt), falls das nicht aufgefallen sein sollte...

Sorry! Danke für die Ergänzung. Jedes Byte im ersten Sektor ist wertvoll.

Erhard Henkes

Ich wollte mal auf die Schnelle in den PM umschalten, macht aber einen Reset. Ich finde momentan den Fehler einfach nicht. Liegt es an GDTR/GDT, am fehlenden IDT oder am far jump?

Vielleicht sollte ich doch auf C umsatteln? Mir gefällt Assembler aber didaktisch besser, weil es klarer ist. Kann bitte jemand nachhelfen?

..

Nobuo T

Ich wuerde spontan auf deine GDT, bzw. GDTR tippen. Bist du dir zB. sicher, dass die Basisadresse im GDTR auch stimmt?

Erhard Henkes

Nein, ich habe da zu viel aus verschiedenen Ecken zusammen geflickt. Das funktioniert leider auch nicht, denke aber, dass es so richtig ist:

gdtr: 
      dw gdt_end - gdt - 1 ; lenght of GDT
      dd gdt

gdt:					   
      dw 0		   ; (0h) Null Segment
      dw 0				   
      db 0				   
      db 0				   
      db 0				   
      db 0

code_gdt equ $-gdt
      dw 0x0FFFF
      dw 0x0000
      db 0x00
      db 0x9A
      db 0xCF
      db 0x00

data_gdt equ $-gdt
      dw 0x0FFFF
      dw 0x0000
      db 0x00
      db 0x92
      db 0xCF
      db 0x00

video_gdt equ $-gdt
      dw 3999 ; Limit 80*25*2-1
      dw 0x8000
      db 0x0B ; Base 0xB8000
      db 0x92
      db 0x00
      db 0x00

gdt_end:

Die Basis-Adresse ist doch das Label gdt?

Erhard Henkes

Habe gerade mal bei uns im Forum recherchiert:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-219332.html
Da klagt auch jemand über Neustart. Da lag es am far jump.
Naja, aus Fehler kann man ja auch lernen. Da scheitern die meisten.

Wenn ich org 0x10000 vorne rein setze, funktionieren die normalen Befehle im Real Mode. Bei PM stürzt er aber sofort ab.

Wenn ich org 0x7c00 vorne rein setze, funktionieren die normalen Befehle im Real Mode natürlich nicht mehr. Bei PM stürzt er aber nicht mehr ab, aber er zeigt auch nichts an (z.B. 'A'). Man kann dann noch Zeichen eingeben, Puffer von 31 Zeichen läuft noch.

org 0x10000 ist richtig. Wie muss ich den far jump schreiben?

Was ist hier der richtige Selektor für den Jump?

db 0xea	;instruction for FAR JUMP
  dw do_pm      ;Offset for jump
  dw 0x8	;selector of the segment for the jump

 ; jmp code_gdt:do_pm does not work?!

Nobuo T

Tja, das ist eben so eine Sache mit den Labels in Asm. Praktisch sind das ja beim x86 eigentlich immer offsets. Da muss auch jeweils die Basis-Adresse zu stimmen (wird auch beim nasm mittels org festgelegt).

Kurze Ueberlegung:
Wenn du deinen Code nach 0x10000 laedst und die Segmentregister dann mit 0x1000 laedst, klappt das ohne, bzw. mit org 0 natuerlich erstmal im RM problemlos, da dein Code an Offset 0 des Segments direkt beginnt. Im GDTR muss dann aber die physikalische mit absoluter Basis 0 stehen! Das selbe beim far jump zum PM - der offset-Teil muss dort dann relativ zur Basisadresse, die im angegebenen Code-Selector steht, passen.
Wenn du stattdessen einfach so die labels da rein schreibst, ohne zu beruecksichtigen, dass sich deren Adresse so ohne Weiteres nur auf das RM-Segment 0x1000 beziehen, geht die Sache schief.