Betriebssystembau. 2. Übung. Olaf Spinczyk und Michael Engel Arbeitsgruppe Eingebettete Systemsoftware. Lehrstuhl für Informatik 12 TU Dortmund

Transkript

1 Betriebssystembau 2. Übung Olaf Spinczyk und Michael Engel Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund 1

2 Überblick Bisher Probleme aufgetreten? C++ Crashkurs (Teil 2) Tastatur-Programmierung Aufgabe 2: Unterbrechungsbehandlung für OO-StubBS Betriebssystembau: 2. Übung 2

4 C++-Konzepte (Crashkurs Teil 2) Übersetzungs- und Bindevorgang Präprozessor Vererbung und Mehrfachvererbung Virtuelle Funktionen Betriebssystembau: 2. Übung 4

5 C++ - Übersetzungsprozess Betriebssystembau: 2. Übung 5

6 Sourcecode - Präprozessor Zwei Dateiendungen:.cc C++ Source Code.h Header Files mit Definitionen von Datentypen, Konstanten, Präprozessor-Makros etc. Die Endungen sind Konvention, aber nicht zwingend oft z.b. auch.cpp,.hpp o.ä. Header-Files werden mit Hilfe des Präprozessors textuell in.cc-files integriert #include Anweisung: - #include <iostream> für System-Headerfiles - #include device.h für eigene Headerfiles Betriebssystembau: 2. Übung 6

7 Sourcecode - Präprozessor Weitere Präprozessorfunktionen: Makrodefinition, z.b. für Konstanten: - #define pi #define VGA_BASE 0xb ohne Semikolon am Ende! Bedingte Compilierung: - #ifdef DEBUG... #endif - #ifndef VGA_BASE #define VGA_BASE 0xb8000 #endif Der Präprozessor expandiert Makros im Source Code, fügt Header-Files ein und erzeugt eine neue Textdatei, die der Compiler vorgesetzt bekommt Betriebssystembau: 2. Übung 7

8 Sourcecode - Präprozessor Wichtige Anwendung für #define und #ifndef: Verhindern von mehrfacher Inklusion von Header- Dateien - Header-Dateien dürfen wiederum Header-Dateien inkludieren -> Ringschluss... #ifndef cgastr_include #define cgastr_include #include "object/o_stream.h" #include "machine/cgascr.h" class CGA_Stream /* Hier muesst ihr selbst Code vervollstaendigen */ { /* Hier muesst ihr selbst Code vervollstaendigen */ }; #endif Betriebssystembau: 2. Übung 8

9 Sourcecode - Compiler Erzeugt aus vom Präprozessor vorverarbeitetem Source Code eine Objektdatei (.o) Diese ist i.a. nicht direkt ausführbar, da noch Referenzen auf Funktionen oder Variablen in anderen Objektdateien enthalten sein können Der Compiler überprüft den Source Code auf Syntaxfehler und erzeugt ggf. Fehlermeldungen (errors) Warnungen (warnings) Eine Objektdatei wird nur bei fehlerfreier Übersetzung erzeugt Warnungen führen nicht zum Abbruch des Übersetzungsvorgangs! Sie sollten aber beachtet werden... Betriebssystembau: 2. Übung 9

10 Sourcecode - Linker Der Linker faßt eine Menge an Objektdateien (.o) sowie bei Bedarf Libraries (.a,.so) zu einem ausführbaren Programm zusammen: Auflösung von Referenzen Sortierung der einzelnen Teile der Objektdateien im Speicherabbild der ausführbaren Datei Normalerweise gibt es zwei Link-Modi: dynamisch Libraries werden erst zur Zeit der Ausführung des Programms zum Objektcode geladen und Referenzen darin aufgelöst statisch Libraries werden zur Link-Zeit in ein komplett ausführbares Programm integriert Vor-/Nachteile beider Ansätze? Welcher davon ist für unsere Systementwicklung geeignet? Betriebssystembau: 2. Übung 10

11 Einfache Vererbung Klasse keyboard_interrupt erbt von Klasse interrupt Vererbungsoperator : (entspricht extends in Java) interrupt.h: keyboard_interrupt.h: class interrupt { #include interrupt.h... class keyboard_interrupt : } public interrupt { public: keyboard_interrupt(); ~keyboard_interrupt(); } Betriebssystembau: 2. Übung 11

12 Mehrfachvererbung Klasse keyboard_interrupt erbt von Klassen interrupt und keys: keyboard_interrupt.h: #include interrupt.h class keyboard_interrupt : public interrupt, public keys { public: keyboard_interrupt(); ~keyboard_interrupt(); } Betriebssystembau: 2. Übung 12

13 Virtuelle Funktionen Virtuelle Funktionen sind Funktionen einer Basisklasse. Eine abgeleitete Klasse kann sie überschreiben und übernimmt damit die Ausführung der Funktion für ihre Klassenmitglieder. das funktioniert auch mit nicht virtuellen Klassen... Das Besondere an virtuellen Funktionen ist, dass das Objekt selbst weiss, zu welcher abgeleiteten Klasse es gehört und seine zugehörige Klassenfunktion ruft. Nicht jede Funktion ist standardmäßig virtuell, es muss explizit das Schlüsselwort virtual verwendet werden! (im Gegensatz zu Java) Betriebssystembau: 2. Übung 13

14 Virtuelle Funktionen Ausgabe: Derived ohne das virtual vor void display(): Base #include <iostream> class base { public: virtual void display() { cout<< \nbase ; } }; class derived : public base { public: void display() { cout<< \nderived ; } }; void main() { base *ptr = new derived(); ptr->display(); } Betriebssystembau: 2. Übung 14

15 Virtuelle Destruktoren Es gibt eine Faustregel, die besagt, dass jede Klasse mit virtuellen Funktionen auch einen virtuellen Destruktor haben soll. Da ein nicht virtueller Destruktor nicht gewährleistet, dass abgeleitete Klassen ordnungsgemäß abgebaut werden, kann ein nicht virtueller Destruktor sogar so interpretiert werden, dass der Autor ein Ableiten seiner Klasse nicht vorgesehen hat und wohl auch nicht empfiehlt. Betriebssystembau: 2. Übung 15

17 PC-Tastatur klassisch: moderner PC: USB-Tastatur USB Legacy Support: Ansteuerung funktioniert immer noch zusätzlich über den Tastaturcontroller (Rückwärtskompatibilität) Betriebssystembau: 2. Übung 17

18 Tastenkodierungen Darstellung im Programm (und im CGA-Speicher!): Zeichencodes (ASCII) Darstellung in der Hardware: Tastencodes T a s t e S c a n - C o d e A 3 0 a 3 0 S 3 1 D 3 2 C u r s o r h o c h 7 2 C u r s o r r u n t e r 8 0 Jede Taste hat eindeutigen Tastencode (Scan-Code) Scan-Code ist 7-Bit Zahl (max. 128 Tasten) Tastaturcontroller sendet zusätzliche Informationen Make-Code beim Drücken / Halten einer Taste Break-Code beim Loslassen Betriebssystembau: 2. Übung 18

19 Make- und Break-Codes Üblicherweise gilt Make-Code (Taste gedrückt) = Scan-Code Break-Code (Taste losgelassen) = Scan-Code (Bit 7) Einige Tasten senden jedoch mehrere Codes z.b. Funktionstasten (F1-F12) aus historischen Gründen (XT-Tastatur) bis zu drei Make/Break-Codes pro Taste Eingebaute Wiederholungsfunktion Hardware sendet zusätzliche Make-Codes, wenn eine Taste länger gehalten wird Dekodierung ist mühsam bei OOStuBS in der Vorgabe enthalten: bool key_decoded() Betriebssystembau: 2. Übung 19

20 Datenaustausch mit der Tastatur Tastaturcontroller wird über zwei E/A-Ports angesprochen Ein-/Ausgaberegister (data_port) 0x60 Steuerregister (ctrl_port) 0x64 Lesen Make-Code Break-Code Status der Tastatur Schreiben Keyboard_Controller set_led: LED ein-/aus data_port set_speed: Wiederholungsrate ctrl_port cpu_reset: Warmstart... Betriebssystembau: 2. Übung 20

21 Status der Tastatur Statusregister stellt folgende Informationen bereit: Betriebssystembau: 2. Übung 21

22 Status der Tastatur - Verwendung Aktive Tastaturabfrage (nicht durch Unterbrechungen): Warten, bis outb in ctrl_port gesetzt ist Make-/Break-Code vom data_port lesen (löscht ctrl_port.outb) Tastatur programmieren (set_led, set_speed) Befehlsbyte in data_port schreiben Tastatur antwortet mit ack (0xfa), ggfs. auf Antwort warten (s.o.) Datenbyte in data_port schreiben (LED-Codes, Repeat-Rate) Tastatur antwortet mit ack, ggfs. auf Antwort warten Betriebssystembau: 2. Übung 22

23 Tastatur programmieren set_led 0xed, <led_mask> in data_port set_speed 0xf3, <config_byte> in data_port Parameter für set_led Befehl: (led_mask) Parameter für set_speed Befehl: (config_byte) Betriebssystembau: 2. Übung 23

25 Hardware-IRQs bei x86 CPUs Bis einschließlich i486 hatten x86 CPUs nur einen Interrupt-Eingang (INT) plus einen NMI Eingang INT kann mit dem IE-Bit im Statuswort maskiert werden - cli-befehl (clear interrupt enable) Interruptverarbeitung sperren - sti-befehl (set interrupt enable) Interruptverarbeitung freigeben NMI kann auf der CPU nicht maskiert werden (sagt ja schon der Name) - beim PC aber trotzdem durch externe Hardware... Externer Controller muss Nummer auf den Bus legen Beim PC ist das der Programmable Interrupt Controller 8259A Datenaustausch zwischen CPU und PIC 8259A erfolgt nach einem festgelegtem Protokoll Betriebssystembau: 2. Übung 25

26 Ablauf eines Hardware IRQ (mit PIC) PIC 8259A CPU (i386) Applikation IDT Handler <n> INT-Pin <interruption> Hardware INTA-Pin <n> (8 Bit, Datenbus) INTA-Pin Software EOI-Befehl (konfigurationsabhängig) <continue> IRET Befehl Betriebssystembau: 2. Übung 26

27 Kaskadierung im PC (15 Interrupts) Betriebssystembau: 2. Übung 27

28 i386 Interrupt-Deskriptortabelle (IDT) maximal 256 Einträge - Basisadresse und Größe in IDTR 8 Byte pro Eintrag (Gate) - Task-Gate (Hardwaretasks) - Trap-Gate (Ausnahmehandler) - Interrupt-Gate (Ausnahmehandler + cli) IDTR Betriebssystembau: 2. Übung 28

29 i386 IDT: Aufbau IDT Traps Hardware/Software IRQs Einträge 0-31 für Traps (fest) Trap = Ausnahme, die synchron zum Kontrollfluss auftritt Number Description 0 Divide-by-zero 1 Debug exception 2 Non-Maskable Interrupt (NMI) 3 Breakpoint (INT 3) 4 Overflow - Division durch 0 5 Bound exception - Seitenfehler 6 Invalid Opcode 7 FPU not available - Unterbrechungspunkt 8 Double Fault 9 Coprocessor Segment Overrun Invalid TSS 11 Segment not present 12 Stack exception Einträge für 13 General Protection IRQs (variabel) - Software (INT <nummer>) 16 Floating-point error - Hardware (INT-Pin der CPU 17 Alignment Check auf HIGH, Nummer auf 18 Machine Check Reserved By Intel Datenbus) Betriebssystembau: 2. Übung Page fault 15 Reserved

30 Zustandssicherung Wenn eine Unterbrechung eintritt, sichert die CPU automatisch einen Teil des Zustands auf dem Stapel condition codes (eflags) aktives Codesegment (cs) Rücksprungadresse (eip) esp eflags cs eip esp - 12 esp - 8 esp - 4 Der automatisch gesichterte Zustand wird bei der Ausführung von iret zurückgesetzt verwendet der Handler weitere Register, so muss er diese selber sichern! Betriebssystembau: 2. Übung 30

31 PIC 8259A Interner Aufbau höchste niedrigste Betriebssystembau: 2. Übung 31

32 Zugriff auf die PICs über IO-Ports Jeder PIC hat zwei Ports, die gelesen/geschrieben werden können Schreibdaten: ICW1-4, OCW1-3 - ICW = Initialization Control Word Initialisierung des PICs - OCW = Operation Control Word Kommandos im Betrieb Lesedaten abhängig von Kommando Lesen IRR ISR Offset IMR <wie Master> Master Port 0x20 Port 0x21 Slave Port 0xa0 Port 0xa1 Schreiben ICW1 (Initialisierung beginnen) OCW2 (EOI,...) OCW3 (IRR lesen, ISR lesen,...) ICW2-4 (Initialisierungsdaten) OCW1 (= IMR) <wie Master> Betriebssystembau: 2. Übung 32

33 Initialisierung der PICs Teil 1 OO-Stubs Einstellung: Master Slave OO-Stubs Einstellung: Master Slave Betriebssystembau: 2. Übung 33

34 Mapping der HW-IRQs (OO-Stubs) IDT Traps HW <unbenutzt> Standard AT IRQ-Belegung IRQ 0 IRQ 1 IRQ 2 System Timer IRQ 3 COM 2 IRQ 4 COM 1 IRQ 5 Tastatur (Keyboard) PIC Kaskadierung IRQ 6 Floppy IRQ 7 LPT 1 IRQ 8 CMOS Echtzeituhr IRQ 9 (HW-Mapping von IRQ 2) IRQ10 IRQ11 IRQ12 PS/2 IRQ13 numerischer Coprozessor IRQ14 1. IDE Port IRQ15 2. IDE Port Betriebssystembau: 2. Übung 34

35 Initialisierung der PICs Teil 2 OO-Stubs Einstellung: Master Slave OO-Stubs Einstellung: Master Slave Betriebssystembau: 2. Übung 35

36 Programmierung der PICs Interruptmaske (IMR) - schreiben und lesen über Port 0x21 / 0xa1 Betriebssystembau: 2. Übung 36

37 Interrupthandler in OO-Stubs Behandlung startet in der Funktion guardian() bekommt die IRQ-Nummer als Parameter: void guardian( unsigned int slot ) {... // IRQ-Handler (Gate) aktivieren } Interrupts sind während der Abarbeitung gesperrt - können mit sti manuell wieder zugelassen werden - werden automatisch wieder zugelassen, wenn guardian() terminiert Die eigentlichen (spezifischen) IRQ-Handler sind Instanzen der Klasse Gate werden an- und abgemeldet über die Klasse Plugbox Betriebssystembau: 2. Übung 37

38 Interrupthandler in OO-Stubs Betriebssystembau: 2. Übung 38