Hardware-Multitasking — Änderungen 6843 → 6847

Zeile 5:

=== Das Task State Segment ===

−

Hardware-Multitasking beruht auf dem sogenannten Task State Segment, welches jedem Task zugeordnet wird und unter anderem dessen Registerwerte speichert. Der Aufbau des TSS wird [[TSS|hier exakt]] beschrieben. ~~Vereinfacht sieht er so aus~~:

#'''statische Felder''' werden einmal mit Werten belegt und dann jeweils beim Taskwechsel von der CPU in die entsprechenden Register geladen, aber niemals automatisch verändert. Zu den statischen Feldern zählen IOMap Base Adress, LDT Segment Selektor, CR3, ESP0-2 und SS0-2. Das CR3-Feld muss nicht initialisiert werden, wenn Paging nicht aktiv ist, ebenso der LDT Selektor, falls man keine LDTs verwendet. Mit der IOMap kann man bestimmte Ports maskieren, auf die der Task kein Zugriff haben soll. IOMap Base Adress kann Null gesetzt werden, wenn man diese Funktion der CPU nicht nutzen möchte.

−

~~[[Datei:Tss~~.~~jpg]]~~

#'''dynamische Felder''' müssen auch initalisiert werden, werden dann aber beim Taskwechsel von der CPU immer mit den entsprechenden geänderten Registerwerten belegt. Zu den dynamischen Feldern gehören EAX-EDX, CS-GS/SS, EFLAGS, ESI/EDI/EBP/ESP und Previous Task Link.

−

Die dynamischen Felder werden von der CPU automatisch beim Taskwechsel mit den entsprechenden Registerwerten des laufenden Tasks gefüllt. Die statischen Felder werden mit Anfangswerten belegt und später nicht mehr verändert. Meiner Meinung nach nicht so entscheidende Felder sind die als unwichtig markierten (alle Felder sind 32 Bit lang).

Der Speicherort des TSS wird als Eintrag in der GDT gespeichert. Der Selektor dieses Eintrags wird im Task Register der CPU gespeichert, wodurch sie bei einem Taskwechsel weiß, wo die (dynamischen) Registerwerte gespeichert werden sollen, damit diese beim Wiederaufruf des Tasks unverändert sind. Folgender Code legt ein TSS an und erzeugt dann den Descriptor in der GDT, der darauf zeigt.

@@ Zeile 5: / Zeile 5: @@
 === Das Task State Segment ===
-Hardware-Multitasking beruht auf dem sogenannten Task State Segment, welches jedem Task zugeordnet wird und unter anderem dessen Registerwerte speichert. Der Aufbau des TSS wird [[TSS|hier exakt]] beschrieben. Vereinfacht sieht er so aus:
+Hardware-Multitasking beruht auf dem sogenannten Task State Segment, welches jedem Task zugeordnet wird und unter anderem dessen Registerwerte speichert. Der Aufbau des TSS wird [[TSS|hier exakt]] beschrieben. Man kann die Felder dabei in zwei Kategorien einteilen:
+#'''statische Felder''' werden einmal mit Werten belegt und dann jeweils beim Taskwechsel von der CPU in die entsprechenden Register geladen, aber niemals automatisch verändert. Zu den statischen Feldern zählen IOMap Base Adress, LDT Segment Selektor, CR3, ESP0-2 und SS0-2. Das CR3-Feld muss nicht initialisiert werden, wenn Paging nicht aktiv ist, ebenso der LDT Selektor, falls man keine LDTs verwendet. Mit der IOMap kann man bestimmte Ports maskieren, auf die der Task kein Zugriff haben soll. IOMap Base Adress kann Null gesetzt werden, wenn man diese Funktion der CPU nicht nutzen möchte.
-[[Datei:Tss.jpg]]
+#'''dynamische Felder''' müssen auch initalisiert werden, werden dann aber beim Taskwechsel von der CPU immer mit den entsprechenden geänderten Registerwerten belegt. Zu den dynamischen Feldern gehören EAX-EDX, CS-GS/SS, EFLAGS, ESI/EDI/EBP/ESP und Previous Task Link.
-Die dynamischen Felder werden von der CPU automatisch beim Taskwechsel mit den entsprechenden Registerwerten des laufenden Tasks gefüllt. Die statischen Felder werden mit Anfangswerten belegt und später nicht mehr verändert. Meiner Meinung nach nicht so entscheidende Felder sind die als unwichtig markierten (alle Felder sind 32 Bit lang).
 Der Speicherort des TSS wird als Eintrag in der GDT gespeichert. Der Selektor dieses Eintrags wird im Task Register der CPU gespeichert, wodurch sie bei einem Taskwechsel weiß, wo die (dynamischen) Registerwerte gespeichert werden sollen, damit diese beim Wiederaufruf des Tasks unverändert sind. Folgender Code legt ein TSS an und erzeugt dann den Descriptor in der GDT, der darauf zeigt.