Betriebssystembau. 7. Übung. Michael Engel Arbeitsgruppe Eingebettete Systemsoftware. Lehrstuhl für Informatik 12 TU Dortmund

Transkript

1 Betriebssystembau 7. Übung Michael Engel Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund 1

2 Agenda Coroutinen vs. Prozeduren Laufzeitkontext und Aufrufkonventionen auf x86 Implementierung von Kontextwechseln allgemein konkret in Aufgabe 4 Betriebssystembau: 7. Übung 2

3 Multitasking Coroutinen Coroutinen sind die Basis für Prozesse Prozeduren mit eigenem Laufzeitkontext (Stack) der Kontrollfluss kann explizit von einer Coroutine zur anderen transferiert werden viel mächtiger als Prozeduraufrufe der Kontrolltransfer ist nicht wie bei Prozeduraufrufen auf hierarchische Strukturen eingeschränkt Coroutinen sind unabhängige Aktivitäten...sie können explizit suspendiert und wiederaufgenommen werden in Programmiersprachen wie Simula 67 und Modula 2 bereits in die Sprache integriert in C/C++ nicht... Betriebssystembau: 7. Übung 3

4 Coroutinen vs. Prozeduren Prozeduren werden immer komplett durchlaufen 1.Die Prozedur wird aufgerufen 2... vollständig abgearbeitet und kehrt zur aufrufenden Prozedur zurück. Coroutinen transferieren den Kontrollfluss Die Coroutine wird initialisiert und gestartet sie kann während der Abarbeitung die Kontrolle zu einer anderen Coroutine transferieren und später genau an der Stelle weiterarbeiten, an der sie die Kontrolle abgegeben hat - der lokale Laufzeitkontext (lokale Variablen) bleibt dabei vollständig erhalten Betriebssystembau: 7. Übung 4

5 Coroutinen vs. Prozeduren Betriebssystembau: 7. Übung 5

6 Prozeduren asymmetrisches Aufrufmodell drei Phasen werden unterschieden: 1. Aktivierung durch einen Aufruf - Aufbau eines Aktivierungsblocks 2. Ausführung - Veränderung des lokalen Datenraums 3. Beendigung durch einen Rücksprung - Abbau des Aktivierungsblocks geschachtelte Aufrufe sind üblich Betriebssystembau: 7. Übung 6

7 Prozeduren besitzen einen Laufzeitkontext der u.a. das Ziel für den Rücksprung angibt die Rücksprungadresse - wird beim return in den PC geladen - ist variabel, weil ein und dieselbe Prozedur von vielen Stellen aus aufgerufen werden kann - zeigt auf die dem jeweiligen Aufruf folgende Instruktion Der Aktivierungsblock (Activation Record) enthält mindestens folgende Informationen: - 1. Rücksprungadresse - 2. lokale Basis liegt je nach Prozessortyp und Compiler auf dem Stack oder in CPU- Registern vor Betriebssystembau: 7. Übung 7

8 Laufzeitkontext Basisregister Bei x86: ebp base pointer definiert die lokale Basis für Parameter und lokale Variable der aktuellen Prozedur auf dem Stack dient als relative Adressierungsbasis übergebene Parameter werden über positive Offsets zum Basisregister erreicht lokale Variablen werden über negative Offsets zum Basisregister erreicht Betriebssystembau: 7. Übung 8

9 Geschachtelte Prozeduraufrufe Betriebssystembau: 7. Übung 9

10 Aufrufkonventionen Aufrufkonventionen legen fest die Art der Parameterübergabe - über den Stack - oder über Register - oder eine Kombination aus beiden welche Registerinhalte die aufgerufene Prozedur erhalten muss - nicht-flüchtige Register und welche Registerinhalte zerstört werden dürfen - flüchtige Register (Scratch Register) Aufrufkonventionen sind abhängig vom Compiler und vom CPU-Typ wichtig beim Linken von Objektcode, der von unterschiedlichen Compilern erzeugt wurde daher existieren oft Vorgaben zu Aufrufkonventionen in den sog. ABIs (Application Binary Interface) Betriebssystembau: 7. Übung 10

11 Beispiel: x86 CISC-CPU mit nur wenigen Registern alle Parameter werden über den Stack übergeben nur 8 nutzbare Register, jeweils 32 Bit breit eax,ecx,edx sind flüchtig esi,edi,ebx sind nicht-flüchtig lokale Basis in ebp Stackpointer in esp Rückgabewerte in eax Betriebssystembau: 7. Übung 11

12 Prozeduraufruf // void bar() { //... // foo(88, 19, 17); // }... push 17 ; Der letzte Parameter zuerst push 19 ; Der 2. Parameter als naechstes push 88 ; Der 1. Parameter zuletzt call foo ; push &RA, Sprung nach for RA: add esp,12 ; Parameter entfernen... Betriebssystembau: 7. Übung 12

13 Lokaler Datenraum foo: push ebp; ; lokale Basis des Aufrufers retten mov ebp,esp ; eigene lokale Basis setzen sub esp,24 ; Platz f. lokale Variablen schaffen push ebx ; nicht fluechtige Register retten push esi ; push edi ;... pop edi ; gerettete Register restaurieren pop esi ; pop ebx ; mov esp,ebp ; Stack abraeumen pop ebp ; alte lokale Basis wiederherstellen ret ; zurueck zum Aufrufer Betriebssystembau: 7. Übung 13

14 Zugriff auf Variablen und Parameter foo:... mov eax,[ebp+8] ; erster Parameter nach eax mov ebx,[ebp+12] ; zweiter Parameter nach ebx mov ecx,[ebp+16] ; dritter Parameter nach ecx... mov [ebp 4],eax ; eax in erste lokale Variable mov [ebp 8],ebx ; ebx in 2.lokale Variable mov [ebp 12],ecx ; ecx in 3.lokale Variable... Betriebssystembau: 7. Übung 14

15 Aufbau eines Aktivierungsblocks Betriebssystembau: 7. Übung 15

16 Prozeduren vs. Coroutinen folgendes können wir bisher festhalten: 1. eine Coroutine kann als kooperative Prozedur angesehen werden - sie wird initial als Prozedur aufgerufen 2. diese Prozedur implementiert einen autonomen Kontrollfluss - der einen eigenen Stack besitzt - der (logisch) einen eigenen Registersatz der CPU hat 3. die Erzeugung einer Coroutine bedeutet zweierlei: - Stack und Registersatz anlegen - beides für den initialen Kontextwechsel vorbereiten Betriebssystembau: 7. Übung 16

17 Kontrollflusswechsel ist i.a. nicht in höheren Programmiersprachen machbar es sei denn, das Coroutinenkonzept ist sprachlich unterstützt wie z.b. in Modula-2, im Gegensatz zu C/C++ Übergang zur Assembler-Sprachebene ist (leider?) unvermeidlich Prozessorzustand austauschen, bei x86: 1. Kontext der zu deaktivierenden Coroutine sichern - (a) ebp, ebx, esi und edi auf den Stack retten - oder alternativ die Register direkt im Kontrollfluss-Statusblock sichern - (b) und esp im Kontrollfluss-Statusblock sichern 2. Kontext der zu aktivierenden Coroutine wieder herstellen - (a) esp aus dem Kontrollfluss-Statusblock laden - (b) edi, esi, ebx und ebp wiederherstellen - (c) und einfach zurückkehren Betriebssystembau: 7. Übung 17

18 Stackwechsel bei Coroutinen Betriebssystembau: 7. Übung 18

19 Aufsetzen einer Coroutine prozessorabhängige Datenstruktur die im einfachsten Falle nur den letzten Wert des Stack Pointers sichert... oder den (nicht-flüchtigen) Prozessorregistersatz beschreibt Betriebssystembau: 7. Übung 19

20 Aufsetzen einer Coroutine Betriebssystembau: 7. Übung 20

21 Initialisierung des Stacks Betriebssystembau: 7. Übung 21

22 Geschachtelte Prozeduraufrufe Betriebssystembau: 7. Übung 22

23 Initialer Stack, gcc-konvention 80x86 struct SetupFrame { unsigned edi; // nichtfl. Register unsigned esi; // nichtfl. Register unsigned ebx; // nichtfl. Register void* bp; // Register fuer lokale basis void (*coroutine)(parameter); // Startadresse der Corout. void* nirvana; // simulierte Ruecksprungadresse Parameter arg; // Parameter an coroutine }; Betriebssystembau: 7. Übung 23

24 Parameterübergabe an Coroutinen erfolgt je nach Prozedurkonvention über aufgesetzten Stack, falls Parameter über den Stack übergeben werden oder notfalls über spezielle Assemblerroutinen - Parameter werden i.d.r. über flüchtige Register übergeben - stattdessen Parameter aus Registern auslesen und über den Stack übergeben - und spezielle Hochfahrroutine als Startpunkt angeben, die einfach die entsprechenden Register mit den Werten vom Stack initialisiert Betriebssystembau: 7. Übung 24

25 Zusammenfassung eine Coroutine wurde als kooperative Prozedur implementiert kooperative Prozeduren aktivieren sich gegenseitig... sie führen Kontextwechsel durch sie geben freiwillig die Kontrolle über den Prozessor ab sie verhalten sich eben kooperativ... ohne sich jedoch direkt aufzurufen eine kooperative Prozedur ist ein autonomer Kontrollfluss der einen eigenen Stack und Prozessorregistersatz besitzt ein autonomer Kontrollfluss stellt einen Aktivitätsträger dar der in einem OO-Kontext als aktives Objekt aufgefasst werden kann Betriebssystembau: 7. Übung 25

26 OOStubs Aufgabe 4 Betriebssystembau: 7. Übung 26

27 Aufgabenteil a: Coroutine Koroutinenwechsel von Hand Betriebssystembau: 7. Übung 27

28 toc Strukturelemente void *ebx, *esi, *edi, *ebp, *esp; Funktionen void toc_settle (struct toc* regs, void* tos, void (*kickoff)(void*), void* object); Diese Funktion bereitet die Struktur toc für die erste Aktivierung vor. void toc_go (struct toc* regs); Diese Funktion lädt die Prozessorregister mit den Inhalten der Struktur regs. void toc_switch (struct toc* regs_now, struct toc* regs_then); Diese Funktion führt einen Kontextwechsel durch. Dazu brauchen nur die aktuellen Registerwerte in regs_now gesichert und durch die Werte von regs_then ersetzt werden. Betriebssystembau: 7. Übung 28

29 Coroutine Methoden Coroutine (void* tos); Im Coroutinen Konstruktor werden die Registerwerte so initialisiert, dass der Stackpointer initial auf tos zeigt und bei der ersten Aktivierung die Ausführung mit der Funktion kickoff beginnt. void go (); Diese Methode dient der ersten Aktivierung der ersten Koroutine im System. Daher müssen hier keine Registerwerte gerettet werden. void resume (Coroutine& next); Mit dieser Methode wird ein Koroutinenwechsel ausgelöst. virtual void action () = 0; Die Methode action stellt die eigentliche Aufgabe der Koroutine dar. Betriebssystembau: 7. Übung 29

30 Aufgabenteil b: Dispatcher Koroutinenwechsel über den Dispatcher Betriebssystembau: 7. Übung 30

31 Dispatcher Beschreibung Der Dispatcher verwaltet den Life-Pointer, der die jeweils aktive Koroutine angibt und führt Prozesswechsel durch. Methoden Dispatcher () Der Konstruktor initialisiert den Life-Pointer mit Null, um anzuzeigen, dass noch keine Koroutine bekannt ist. void go (Coroutine& first) Mit dieser Methode wird die Koroutine first im Life-Pointer vermerkt und gestartet. void dispatch (Coroutine& next) Diese Methode setzt den Life-Pointer auf next und führt einen Koroutinenwechsel vom alten zum neuen Life-Pointer durch. Coroutine* active () Hiermit kann abgefragt werden, welche Koroutine gerade im Besitz des Prozessors ist. Betriebssystembau: 7. Übung 31

32 Aufgabenteil c: Kooperatives Scheduling Koroutinenwechsel über Scheduler Betriebssystembau: 7. Übung 32

33 Entrant Beschreibung Die Klasse Entrant erweitert die Klasse Coroutine um die Möglichkeit, in einfach verkettete Listen eingetragen zu werden, insbesondere auch in die Ready-Liste des Schedulers. Die Verkettungsmöglichkeit wird durch die Ableitung von Chain erreicht. öffentliche Methoden Entrant (void* tos); Der Entrant Konstruktor gibt nur den Parameter tos an den Coroutinen Konstruktor weiter. Betriebssystembau: 7. Übung 33

34 Scheduler Beschreibung Der Scheduler verwaltet die Ready-Liste (ein privates Queue Objekt der Klasse), also die Liste der lauffähigen Prozesse (Entrant Objekte). Die Liste wird von vorne nach hinten abgearbeitet. Dabei werden Prozesse, die neu im System sind oder den Prozessor abgeben, stets an das Ende der Liste angefügt. öffentliche Methoden void ready (Entrant& that) Mit dieser Methode wird der Prozess that beim Scheduler angemeldet. Er wird an das Ende der Ready- Liste angefügt. void schedule () Diese Methode setzt das Scheduling in Gang, indem der erste Prozess von der Ready-Liste entfernt und aktiviert wird. void exit () Hiermit kann sich ein Prozess selbst beenden. Er wird nun nicht wieder an das Ende der Ready-Liste angefügt. Statt dessen wird nur der erste Prozess von der Ready-Liste heruntergenommen und aktiviert. void kill (Entrant& that) Mit dieser Methode kann ein Prozess einen anderen (that) beenden. Der Prozess that wird einfach von der Ready-Liste entfernt und erhält somit nie wieder den Prozessor. void resume () Hiermit kann ein Prozesswechsel ausgelöst werden, ohne dass der aufrufende Entrant wissen muss, welche anderen Entrant Objekte im System existieren und welcher davon sinnvollerweise aktiviert werden sollte. Betriebssystembau: 7. Übung 34