Seite 1 von 5

ChangeLog

Verfasst: So Nov 02, 2008 12:32 pm
von Dirty Oerti
So, hier gibt's den versprochenen ChangeLog :)
Es gibt ihn erst jetzt, weil ich so lange gebraucht habe, um das Multitasking hinzubekommen.
So wie's jetzt aussieht, funktionierts aber :)

Ein paar Änderungen werden daran noch passieren, aber vom Grundaufbau her passt's jetzt schon :)

Außerdem ist alles noch recht....durcheinander und "unaufgeräumt".
Darum werde ich mich auch noch kümmern :)

Re: ChangeLog

Verfasst: So Nov 02, 2008 1:08 pm
von Xin
Dirty Oerti hat geschrieben:So, hier gibt's den versprochenen ChangeLog :)
Es gibt ihn erst jetzt, weil ich so lange gebraucht habe, um das Multitasking hinzubekommen.
So wie's jetzt aussieht, funktionierts aber :)
Dann wird's langsam mal Zeit, dass ich mir den Kram mal richtig angucke und vielleicht auch was von Dir lerne.
Ich hoffe nächstes WE habe ich den Rechner neu aufgesetzt und wieder etwas Luft :-)

Du arbeitest mit Bochs oder wie das Virtualisierungstool heißt? Vielleicht kannst du das etwas beschreiben, ich kenne das nämlich noch nicht.

Re: ChangeLog

Verfasst: Mo Nov 03, 2008 8:05 pm
von nufan
Bild
Gratuliere :)

Re: ChangeLog

Verfasst: Mo Nov 03, 2008 10:11 pm
von Dirty Oerti
Danke^^ :)
Muss aber, wie gesagt noch ein bisschen angepasst und optimiert werden.
Was ich schonmal kurz versucht habe ist in den User Mode zu wechseln...
Das kommt als nächstes drann...
Scheiterte beim ersten Versuch kläglich (bochs ist "gestorben" :D ich musste ihn killen...)...

Zu bochs: (Kommt auch mal ins Wiki, bei Zeit)

bochs ist ein x68 und AMD64 Virtualisierungstool/Emulator.
Windows/Linux kann darauf ausgeführt werden (wobei sich die Geschwindigkeit eher in Grenzen hält..)
Gesteuert wird die Simulation über eine Konfigurationsdatei, die beim Aufruf mit angegeben werden kann.
Eine solche Konfig kann so aussehen:

Code: Alles auswählen

# Größe des Hauptspeichers.
megs:128

# Wo stecken BIOS und VGA-ROM?
romimage: file="/usr/share/bochs/BIOS-bochs-latest"
#vgaromimage: VGABIOS-elpin-2.40
vgaromimage: file="/usr/share/vgabios/vgabios.bin"


# Ein Diskettenlaufwerk, in dem eine Diskette steckt.
#floppya: 1_44=a:, status=inserted
floppya: image=floppy.img, status=inserted

# Bootlaufwerk festlegen.
boot: a

# Datei für Protokoll und Fehlermeldungen.
log: protokoll.log

# Die Maus sollte man solange nicht verwenden, wie es auch
# das emulierte Betriebssystem nicht tut.
mouse: enabled=0

# Ausgabe des Debuggers.
debugger_log: debug.log
#debugger_log: -

# Kein Reset bei triple Fault
cpu: count=1, reset_on_triple_fault=0

# Was tun bei welchem Fehler?
panic: action=ask
error: action=report
info: action=report
debug: action=ignore

#config_interface: wx

Re: ChangeLog

Verfasst: Mo Nov 10, 2008 11:56 pm
von Dirty Oerti
Ich habe mal den Code für IRQs und IRSs überarbeitet.
Im Endeffekt wird nun mehr Code generiert, es entstehen Wiederholungen.

Sinn des Ganzen ist folgendes:

Vorher sah's so aus:

Code: Alles auswählen

_isrX:
   push 0
   push X
   jmp _isr_handler


;(...)

_isr_handler:
;(...)
Nun sieht's so aus:

Code: Alles auswählen

_isrX:
  push 0
  push X
  ; Hier kommt nun das, was in _isr_handler drin war
;(...)
Dadurch wird der Code in _isr_handler mehrfach gespeichert, ich spare mir aber den Aufruf. :)

Außerdem habe ich ein paar unnuütze Pushs bei den IRQs entfernt :)

Auf lange Sicht hin überlege ich mir, den Header kernel.h zu entfernen und das über einzelne Header zu lösen.

REVISION 61

Re: ChangeLog

Verfasst: Di Nov 11, 2008 8:58 am
von Xin
Dirty Oerti hat geschrieben:Ich habe mal den Code für IRQs und IRSs überarbeitet.
Im Endeffekt wird nun mehr Code generiert, es entstehen Wiederholungen.

Sinn des Ganzen ist folgendes:

Dadurch wird der Code in _isr_handler mehrfach gespeichert, ich spare mir aber den Aufruf. :)
Du rufst mit JMP nichts auf, sondern Du änderst das IP-Register.
Der JMP Befehl kommt - afaik - gar nicht im im CPU Kern an, sondern die Ladeeinheit lädt bereits automatisch bei _isr_handler weiter.
Oder meinst Du JSR?

Wenn Du Rechenzeit sparen willst, solltest Du überlegen, dass Du die Stack-Operationen sparen könntest, z.B. durch Registerübergaben statt den Stack zu nutzen.
Heißt: wenn Du irgendwohin springst, erwartest Du die Eingabedaten in ax, bx. Das ganze hat natürlich nur Sinn, wenn die Routine danach zum Rechnen nicht auf den Stack auslagern muss.

Re: ChangeLog

Verfasst: Di Nov 11, 2008 3:12 pm
von Dirty Oerti
Xin hat geschrieben:Du rufst mit JMP nichts auf, sondern Du änderst das IP-Register.
Der JMP Befehl kommt - afaik - gar nicht im im CPU Kern an, sondern die Ladeeinheit lädt bereits automatisch bei _isr_handler weiter.
Das wusste ich nicht.
Ist es aber im Endeffekt nich doch weniger zu tun und damit schneller? (Wenn auch nur minimal)

Ich werde es aber trotzdem so lassen, das erhöht, denke ich, die Sicherheit. Wird eine Interruptroutine nun beschädigt, dann funktionieren die anderen trotzdem einwanfrei.
Xin hat geschrieben:Oder meinst Du JSR?
Wie Wo Was?
Du meinst die Assembleranweisung JSR?
Nein, es ist ein "jmp"

Xin hat geschrieben:Wenn Du Rechenzeit sparen willst, solltest Du überlegen, dass Du die Stack-Operationen sparen könntest, z.B. durch Registerübergaben statt den Stack zu nutzen.
Heißt: wenn Du irgendwohin springst, erwartest Du die Eingabedaten in ax, bx. Das ganze hat natürlich nur Sinn, wenn die Routine danach zum Rechnen nicht auf den Stack auslagern muss.
Ich verstehe nicht ganz, was du meinst.
Die Register pushe ich auf den Stack, um sie zu sichern. Sie müssen danach ja wieder genau so hergestellt werden, wie sie vorher waren. Und zwar möglichst alle Register.
Außerdem ermöglicht das mir einen Task Wechsel (ich wechsle in der Interruptroutine einfach den Stack, Folge: Es werden die Werte vom neuen Stack geladen) :)

Oder wie genau meinst du das?

Re: ChangeLog

Verfasst: Di Nov 11, 2008 4:07 pm
von Xin
Dirty Oerti hat geschrieben:
Xin hat geschrieben:Du rufst mit JMP nichts auf, sondern Du änderst das IP-Register.
Der JMP Befehl kommt - afaik - gar nicht im im CPU Kern an, sondern die Ladeeinheit lädt bereits automatisch bei _isr_handler weiter.
Das wusste ich nicht.
Ist es aber im Endeffekt nich doch weniger zu tun und damit schneller? (Wenn auch nur minimal)
Auf einer modernen CPU kein Unterschied.
Dirty Oerti hat geschrieben:Ich werde es aber trotzdem so lassen, das erhöht, denke ich, die Sicherheit. Wird eine Interruptroutine nun beschädigt, dann funktionieren die anderen trotzdem einwanfrei.
Aus der Warte gehst Du falsch an das Problem ran: Nicht redundanter Code stürzt bei Fehlern immer ab - nicht nur gelegentlich.
Dirty Oerti hat geschrieben:
Xin hat geschrieben:Oder meinst Du JSR?
Wie Wo Was?
Du meinst die Assembleranweisung JSR?
Nein, es ist ein "jmp"
Warum pushst Du dann?

Dirty Oerti hat geschrieben:
Xin hat geschrieben:Wenn Du Rechenzeit sparen willst, solltest Du überlegen, dass Du die Stack-Operationen sparen könntest, z.B. durch Registerübergaben statt den Stack zu nutzen.
Heißt: wenn Du irgendwohin springst, erwartest Du die Eingabedaten in ax, bx. Das ganze hat natürlich nur Sinn, wenn die Routine danach zum Rechnen nicht auf den Stack auslagern muss.
Ich verstehe nicht ganz, was du meinst.
Die Register pushe ich auf den Stack, um sie zu sichern. Sie müssen danach ja wieder genau so hergestellt werden, wie sie vorher waren. Und zwar möglichst alle Register.
Außerdem ermöglicht das mir einen Task Wechsel (ich wechsle in der Interruptroutine einfach den Stack, Folge: Es werden die Werte vom neuen Stack geladen) :)

Oder wie genau meinst du das?
Bei Jmp gibt es normalerweise kein danach - da ich aber den Code nicht vollständig kenne und weiß, dass bei den Interrupts einige Besonderheiten beim Intel existieren, will ich mal nix falsches sagen und gehe davon aus, dass Du weißt, was Du tust.

Re: ChangeLog

Verfasst: Di Nov 11, 2008 4:13 pm
von Dirty Oerti
Ah, jetzt :)

Also:
Ursprünglich gab es eine kleine "Interrupteinsprungsfunktion".
Die hat einen Error Code und die Interruptnummer auf den Stack gelegt.
Danach ist sie zum Standardhandler gesprungen.

Dieser hat alle Register auf den Stack gespeichert und dann per call die Interruptroutine im C Code aufgerufen.
Die Interruptroutine hat getan, was sie tun musste, und ist dann zurück in den Standardhandler.

Dieser hat alle Register (vom Stack) wiederhergestellt und ist dann per iretd zurück zum Punkt, an dem unterbrochen wurde.
:)
Ok?

Auf einer modernen CPU kein Unterschied.
Mist.^^
Xin hat geschrieben:Aus der Warte gehst Du falsch an das Problem ran: Nicht redundanter Code stürzt bei Fehlern immer ab - nicht nur gelegentlich.
Aus Sicht eines Debuggenden Menschen hast du Recht, aus Sicht der Sicherheit denke ich, dass es sicherer sein müsste, den Code mehrfach im Speicher zu haben.

Re: ChangeLog

Verfasst: Di Nov 11, 2008 4:37 pm
von Xin
Dirty Oerti hat geschrieben:
Xin hat geschrieben:Aus der Warte gehst Du falsch an das Problem ran: Nicht redundanter Code stürzt bei Fehlern immer ab - nicht nur gelegentlich.
Aus Sicht eines Debuggenden Menschen hast du Recht, aus Sicht der Sicherheit denke ich, dass es sicherer sein müsste, den Code mehrfach im Speicher zu haben.
Aus Sicht der Sicherheit denke ich, dass es sicherer sein müsste, wenn der debuggende Mensch möglichst direkt auf den Fehler gestoßen wird.
Wird ein Code nicht redundant verwendet, so wird die eine Implementierung immer und immer wieder getestet. Die Wahrscheinlichkeit, dass sie funktioniert, steigt also. Funktioniert sie nicht, kann man den Fehler / Breakpoints direkt an diese eine Routine festlegen.

Im Gegenzug dazu, wenn eine redundante Version gelegentlich durchlaufen wird und unter Umständen abstürzt, weiß man in der Regel nicht, was man zuletzt gemacht hat und welche der Implementierungen grade fehlschlägt - sofern man sich an die problematische Implementierung überhaupt grade erinnert.