Grundlagen der Informatik III Wintersemester 2010/2011 – 23

Grundlagen der Informatik III
Wintersemester 2010/2011 – 23. Vorlesung
Dr.-Ing. Wolfgang Heenes
msg:
main:
int main() {
printf("Hello, world!");
return 0;
}
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 1
.data
.asciiz "Hello, world!"
.text
.globl main
la $a0,msg
li $v0,4
syscall
jr $ra
Inhalt
1. Literatur
2. Betriebssysteme I
3. Aufgaben eines Betriebssystems
4. Strukturierungs-/Beschreibungsmethoden
5. Anforderungen an die Systemsoftware
6. Konzept der Unterbrechungen
7. Betriebsarten
8. Zusammenfassung und Ausblick
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 2
Literatur
[Tan09] Tanenbaum, Andrew S.: Moderne Betriebssysteme.
Pearson, 2009.
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 3
Betriebssysteme I
Einführung
I
I
Was ist ein Betriebssystem?
Was ist ein Elefant?
I
I
Eine Maus mit einem Betriebssystem!
Vorstellung und Realität?!
I
I
Hardware: klein, schnell und leistungsfähig
Hardware mit Betriebssystem: groß und langsam
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 4
Betriebssysteme I
Historische Entwicklung
I
Anfänge der Informationsverarbeitung um 1940
I
I
I
I
I
I
diese Entwicklung bewirkte
I
I
I
Rechner werden von Ingenieuren und Wissenschaftlern programmiert, die sie
auch konstruiert haben
Probleme lagen mehr an der Hardware denn an der Programmierung
hohe Hardwarekosten, geringe Softwarekosten
Benutzer schreiben eigenständig Programme für viele Bereiche
Kosten für Programmerstellung stiegen stark an ⇒ teure Hardware soll gut
ausgenutzt werden
Entwicklung von Standardprogrammen für die Steuerung von
Rechnerkomponenten
Entwicklung von Standardprogrammen für die Auftragsabarbeitung
Ausgangspunkt für die Erstellung von Systemsoftware
I
I
monitor system, supervisory system, executive system,
operating system ⇒ Betriebssystem (BS)
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 5
Betriebssysteme I
Definitionen
I
Definition eines Betriebssystems nach DIN 44300
Die Programme eines digitalen Rechensystems, die zusammen mit den
Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten
des digitalen Rechensystems bilden und insbesondere die Abwicklung von
Programmen steuern und überwachen.
I
Definition eines Betriebssystems nach ANSI
Software, which controls the execution of computer programs and which may
provide scheduling, debugging, input/output control, accounting, compilation,
storage assignment, data management and related services.
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 6
Aufgaben eines Betriebssystems I
I
„Veredelung“ der Hardware
I
I
I
I
I
Organisation und Steuerung des Ablaufs
I
I
I
I
I
Geräteüberwachung und -steuerung
einfache, einheitliche E/A-Schnittstelle inkl. Fehlerbehandlung
Unterbrechungsbehandlung
Benutzerschnittstelle
Programmabläufe
E/A parallel zu Programmabläufen
Betriebsmittelverwaltung: Speicher, Prozessoren, Geräte
Protokollierung, Accounting
Langfristige Datenhaltung
I
I
I
I
Hintergrundspeicherverwaltung
Dateiverwaltung, Dateien
Schutz von Dateien
Dateisicherung, Archivierung
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 7
Aufgaben eines Betriebssystems II
I
Einhaltung von Qualitätsanforderungen, z. B.
I
I
I
I
I
Warum wird also die Maus zum Elefant?
zunehmende Anforderungen an das Rechensystem, z. B.
I
I
I
I
Leistung (kurze Antwortzeiten, hoher Durchsatz)
Verfügbarkeit
Sicherheit
durch Benutzer: will vieles gleichzeitig, bequem und möglichst schnell
durch Eigentümer: will hohe Auslastung und Verfügbarkeit
u.a. dadurch ⇒ zunehmende Komplexität des Betriebssystems
Somit ermöglicht ein BS den Benutzern einer Rechenanlage eine
I
I
I
ggf. gemeinsame Nutzung
bei einfacher Handhabung
und es verwaltet und steuert die verschiedenen Komponenten eines
Rechensystems mit dem Ziel optimaler Nutzung
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 8
Betriebssysteme I
Eine andere Sicht
Abbildung: Quelle: [Tan09, S. 35]
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 9
Strukturierungs-/Beschreibungsmethoden I
I
Problem
I
I
I
I
I
I
Komplexität muss reduziert werden
Lösung
I
I
BS ist ein umfangreiches Software-System
es besteht aus zahlreichen Komponenten
es existieren zahlreiche Wechselwirkungen zwischen den Komponenten
damit ist es i. d. R. schwer zu verstehen
Verwendung von Strukturierungs- und Beschreibungsmethoden
Strukturierungsmethoden
I
I
I
schichtenweise gegliedertes Betriebssystem
Operationen sind die an jeder Schicht sichtbaren Dienste
⇒ Schichtenmodell optimaler Nutzung
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 10
Strukturierungs-/Beschreibungsmethoden II
I
Beschreibungsmethoden, nötig sind Methoden mit denen
I
I
I
I
I
gegenwärtig existiert keine geschlossene, universell einsetzbare
Beschreibungsmethodik für BS
verwendet werden daher je nach Bedarf u. a.
I
I
I
I
I
strukturelle Zusammenhänge übersichtlich dargestellt werden können
Entwurfs- und Konstruktionskonzepte von BS beschrieben werden können
Algorithmen von BS-Komponenten formuliert werden können
graphische Darstellungen von Objektbeziehungen und Ablaufstrukturen
Spezifikationen von Operationen
programmsprachliche Darstellungen von BS-Software-Fragmenten
⇒ Systemprogrammiersprache
„Eigene“ Systemprogrammiersprache
I
I
orientiert sich an höheren Programmiersprachen wie Pascal, Modula-2
einfache Objekte lassen sich zu komplexeren zusammensetzen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 11
Schichtenmodell
Systemumgebung
Anwendungs-Software
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Systemgrenze . . . . . .
Dienstleistungs-Software
Rechensystem
. . . . . . . . . Software-Schnittstelle . . . . . . . . .
?
Betriebssystem
Software
. . . . . . . . . Software/Hardware-Schnittstelle . . . . . . . . .
Hardware
?
?
Zentraleinheit
. . . . . . . . . Hardware-Schnittstelle . . . . . . . . .
?
Peripheriegeräte
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 12
SystemSoftware
Anforderungen an die Systemsoftware I
I
I
Anforderungsliste I
⇒ unterstützt werden soll u. a.
I
Entwicklung und Anwendung von Programmen durch Benutzer:
I
I
I
I
I
I
I
Entwerfen
Implementieren
Integrieren
Ausführen
Warten
zudem soll dies möglichst schnell, billig, einfach durchzuführen sein
Benutzer soll nicht mit irrelevanten Routinearbeiten überlastet werden ⇒
Benutzer benötigt daher u. a.
I
I
I
I
I
I
I
Assembler, Makros
Übersetzer für problemorientierte Programmiersprachen
Binder, Lader
Editoren, Testhilfen
Dateiverwaltung
E/A-Operationen
Bibliotheken mit Standardunterprogrammen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 13
Anforderungen an die Systemsoftware II
I
Anforderungsliste II
I
wenn mehrere Benutzer das Rechensystem gemeinsam nutzen oder
wenn auch nur ein Benutzer an mehreren Aufgaben arbeitet, dann müssen
I
I
I
Betriebsmittel adäquat verwaltet werden
Betriebsmittelnutzung muss überwacht, gesteuert, ggf. begrenzt, abgerechnet
werden
I
Dienstleistungssoftware oder BS?
I Anforderungsliste I ⇒ i. d. R. durch Dienstleistungssoftware
I Anforderungsliste II ⇒ vor allem durch das Betriebssystem
I
Anforderungen an die Sytemsoftware
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 14
Anforderungen an die Systemsoftware III
Designkriterien
I
Zuverlässigkeit
I
I
I
dependability
die Systemsoftware soll die an sie gestellten Aufgaben auch tatsächlich erfüllen
können
folgende Aspekte sind dabei wesentlich:
I
I
I
I
I
I
Korrektheit (correctness)
Sicherheit (security)
Verfügbarkeit (availability)
Fehlertoleranz (fault tolerance)
Robustheit (robustness)
Benutzerfreundlichkeit
I
I
I
user-friendliness
die Systemsoftware sollte für „Otto-Normal-Benutzer“ vernünftig handhabbar sein
Aspekte sind dabei
I
I
Verständlichkeit (understandability)
vernünftiges Fehlerverhalten
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 15
Anforderungen an die Systemsoftware IV
Designkriterien
I
Wartbarkeit und Flexibilität
I
I
I
I
maintainability, flexibility
das Warten von Programmsystemen soll gut unterstützt werden
Anpassen an neue Gegebenheiten soll mit geringem Aufwand durchführbar sein
wichtige Aspekte sind hierbei
I
I
I
I
I
Testbarkeit (testability)
Erweiterbarkeit (extensibility)
Adaptierbarkeit (adaptability)
Übertragbarkeit (portability)
Leistungsfähigkeit
I
I
I
performance
das System soll seine Funktion in quantifizierbaren Leistungsgrößen möglichst
gut erfüllen
dabei sind wichtig
I
I
I
I
Produktivität (productivity)
Reaktionsfähigkeit (responsiveness)
Auslastung (utilization)
Verwaltungsaufwand (management overhead)
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 16
Anforderungen an die Systemsoftware V
Designkriterien
I
Kosten
I
I
costs
das Preis/Leistungsverhältnis soll möglichst günstig sein
I
Anforderungen sind nicht unabhängig voneinander
I
um Zielanforderungen gerecht werden zu können, muss Systemsoftware
systematisch entworfen und gut strukturiert werden
I
Korrektheit wichtigste Anforderung ⇒ Leistung ist oft überbewertet
Beispiel: Betriebssystem Multics (um 1970)
I
I
I
I
mehrere 100 Arbeitsjahre Entwicklungsaufwand
0.5 Arbeitsjahre für Optimierung (tuning) ⇒ Leistungssteigerung um Faktor 200
Fazit: erst richtig, dann schnell
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 17
Eigenschaften der Zentraleinheit I
I
I
I
Rechnersystem
klassische Zentralstrukturen nach John von Neumann
Zentraleinheit
I
I
I
I
ein oder mehrere Prozessoren
Hauptspeicher, speichert Befehle und Daten
Peripheriegeräte
Klassische Zentralstruktur
Zentraleinheit eines Rechners
Prozessor 1
6
?
Prozessor 2
6
?
Hauptspeicher
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 18
Prozessor 3
6
?
......
Eigenschaften der Zentraleinheit II
I
Eng gekoppeltes symmetrisches Mehrprozessorsystem
I
tightly coupled symmetric multiprocessor system
I
mehrere Prozessoren können parallel tätig sein
I
alle Prozessoren sind funktionsäquivalent ⇒ symmetrisch
I
alle Prozessoren besitzen als einziges einen gemeinsamen Hauptspeicher ⇒
eng gekoppelt, shared memory
I
ist der Standardfall aller nachfolgenden Betrachtungen
I
einfacher Sonderfall: ⇒ Einprozessorsystem
Hauptspeicher
I
I
besteht aus Menge gleichartiger Zellen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 19
Arbeitsweise eines Prozessors I
I
Prozessor arbeitet Befehle ab, die im Hauptspeicher stehen:
1. Prozessor holt nächsten Befehl aus Hauptspeicher (nach aufsteigenden
Adressen)
2. führt Befehl aus
I
dafür benötigt er zwei Steuerregister:
I Befehlsregister IR
I
I
I
enthält den jeweils auszuführenden Befehl
Befehlsregister ist für Software transparent
Befehlszähler IC
I
enthält Adresse des nächsten auszuführenden Befehls
Bezeichner
IR
LOAD . . .
Adresse
i-1
- i
IC
i
Steuerregister
des Prozessors
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 20
i+1
..
.
LOAD . . .
ADD . . .
STORE . . .
..
.
Hauptspeicher M
Arbeitsweise eines Prozessors II
I
einfacher Befehlszyklus
WHILE ‘Maschinenzustand‘ = ‘tätig‘
LOOP
IR := M[IC];
IC += 1;
IR ‘ausführen‘;
REPEAT;
I
sequentielles Abarbeiten
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 21
Arbeitsweise eines Prozessors III
Unterbrechungsmöglichkeiten des sequentiellen Abarbeitens
I Sprungbefehle
I
I
I
I
Unterprogrammaufrufe
I
I
I
Modifikation des Befehlszählers
„Absprungstelle“ wird vergessen
wichtig sind bedingte Sprünge ⇒ Sprung nur bei bestimmten
Prozessorzuständen
wie Sprungbefehl, jedoch wird „Absprungstelle“ gerettet
nach Abarbeitung des Unterprogramms wird „hinter der geretteten
Absprungstelle weitergearbeitet“
Unterbrechungen
I
I
I
I
spezielle Signale an den Prozessor
ändern Kontrollfluss
haben i. d. R. nicht vorhersehbare Ursachen
können aber auch programmgesteuert erzeugt werden
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 22
Arbeitsweise eines Prozessors IV
Betriebszustände eines Prozessors
I
I
Prozessor kann sich in verschiedenen Betriebszuständen befinden
Betriebszustand teilweise definiert durch
I
I
I
Maschinenzustand
Privilegierungszustand
Maschinenzustand
I
I
I
Prozessor kann aus- oder angeschaltet sein
Prozessor kann gerade im Urladevorgang sein
Zustände: stop, laden, tätig
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 23
Arbeitsweise eines Prozessors V
Betriebszustände eines Prozessors
I Privilegierungszustand
I
I
Zustände definieren die Menge der jeweils erlaubten, ausführbaren
Maschinenbefehle
oft existieren
I
I
I
Anwenderzustand: nicht privilegiert; nur eingeschränkter Befehlsvorrat gültig
Systemzustand: privilegiert; voller Befehlsvorrat gültig
Befehl heißt privilegiert, wenn ausschließlich im Systemzustand ausführbar
I
Hardware muss gestatten, Zustandswechsel per Software herbeizuführen
I
Befehlsvorrat z. B. 100-300 Befehle, 10% privilegiert1
1
Intel ⇒ anderes Konzept
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 24
Uhren
Uhren
I Prozessoren besitzen i. d. R. Uhren
I benutzen spezielle Register, z. T. mit Eigenaktivität
I
I
I
I
I
I
Betrieb im Einmal- und Mehrfachmodus möglich
wird u. a. als Zeitgeber (timer) verwendet
I
I
I
I
I
Festwertregister frei einstellbar; Wert wird „initial“ ins Zählerregister kopiert
Zählerregister
in konstanten Zeiteinheiten wird Zählerregisterwert erniedrigt
Auflösung im Mikrosekundenbereich
„Eieruhr“
Festwertregister wird auf speziellen Wert gesetzt
Festwertregisterwert wird ins Zählerregister kopiert und „läuft dann ab“
Erreichen des Wertes 0 erzeugt Unterbrechungsanforderung
im Mehrfachmodus wird bei Erreichen des Nullwertes erneut
Festwertregisterwert ins Zählerregister kopiert
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 25
Konzept der Unterbrechungen I
I
Entwicklung des Unterbrechungskonzeptes auf Wunsch der NASA 1956 mit
UNIVAC 1103 von Remington Rand
I
IBM folgte 1958 mit IBM 709
ohne Unterbrechungen
I
I
mögliche Arbeitsweise
1. Prozessor stösst Tätigkeit eines Gerätes an
2. Gerät arbeitet relativ selbständig während Prozessor auf Beendigung wartet
3. Prozessor arbeitet weiter
I
zeitlich parallele Tätigkeit von Komponenten nicht oder nicht effizient
realisierbar
I
aufgrund relativ geringer Verarbeitungsgeschwindigkeit der Peripheriegeräte
ist Prozessor schlecht ausgelastet
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 26
Konzept der Unterbrechungen II
I
mit Unterbrechungen
I
Arbeitsweise
1. Prozessor stösst Tätigkeit eines Gerätes an
2. Gerät arbeitet relativ selbständig und parallel zum Prozessor, der andere Arbeiten
wahrnimmt
3. am Ende der Tätigkeit meldet sich das Gerät beim Prozessor mit einer Unterbrechung
I
besseres Leistungsverhalten
I
Prozessor und Peripheriegeräte können zeitlich überlappend arbeiten
I
Unterbrechungskonzept verbessert Synchronisation zwischen Prozessor und
Gerät
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 27
Konzept der Unterbrechungen III
Unterbrechung
I
I
interrupt
Signal, das
I
I
Befehlszyklus des Prozessors abändert bzw. unterbricht und
Befehlszyklus an spezifizierter Stelle fortführt
I
Unterbrechung wird durch Eintreten eines speziellen Ereignisses ausgelöst
I
Ereignisursache in Software oder Hardware
grobe Unterbrechungsklassifikation nach Ereignisursache
I
I
I
I
Programmbezogene Unterbrechungen
Systembezogene Unterbrechungen
Maschinenfehler
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 28
Konzept der Unterbrechungen IV
Programmbezogene Unterbrechungen
I der in Ausführung befindliche Befehl löst Unterbrechung aus
I
I
I
I
Unterbrechung trifft Verursacher
synchrone oder interne Unterbrechungen
exceptions
Unterbrechungsursachen sind u. a.
I
I
I
I
arithmetische Fehler (bspw. Division durch Null, Überlauf)
Adressenfehler (bspw. Zugriff auf nicht installierten Speicher, fehlende Rechte)
falsche Befehle (bspw. privilegierter Befehl im Anwenderzustand)
Spezialbefehle zum Einleiten von Systemaufrufen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 29
Konzept der Unterbrechungen V
Systembezogene Unterbrechungen
I
Unterbrechungsursache liegt außerhalb der Prozessoraktivität
I
Unterbrechungsquelle ist ein relativ selbständig arbeitendes Gerät
I
Unterbrechung trifft das zufällig laufende Programm ⇒ asynchrone oder
externe Unterbrechung
Beispiele:
I
I
I
I
Zeitgeberunterbrechungen
E/A-Unterbrechungen
Prozessoranrufe
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 30
Konzept der Unterbrechungen VI
Laden
Zeitgeber
Prozessor
Starten
Prozessor
Gerät
Anrufen
Prozessor 1
Prozessor 2
Anrufen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 31
Konzept der Unterbrechungen VII
Maschinenfehler
I Beispiel:
I
I
I
Abarbeitung von Unterbrechungen
unterschieden wird zwischen
I
I
I
I
Ausfälle einzelner Hardware-Komponenten
Anforderung (request) einer Unterbrechung
Annahme einer Unterbrechung
mit Eintreten des Unterbrechungsereignises wird Unterbrechung angefordert
abhängig vom Prozessorzustand kann Unterbrechung
I
I
erlaubt (enabled) oder
verboten (disabled) sein
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 32
Konzept der Unterbrechungen VIII
Abarbeitung von Unterbrechungen
I
I
I
ist Unterbrechung angefordert und erlaubt, dann kann sie angenommen
werden
ist Unterbrechung angefordert und verboten, dann bleibt sie anstehend
(pending) bis Erlaubnis erteilt wird
I ⇒ Maskieren von Unterbrechungen
I ⇒ Unterbrechungssperren
Unterbrechungsannahme kann erfolgen, wenn
1. eine erlaubte Unterbrechung angefordert wird
2. eine anstehende Unterbrechung erlaubt wird
I
es können zu einem Zeitpunkt mehrere Unterbrechungen anstehen
I
es kann jedoch zu einem Zeitpukt nur eine erlaubte, anstehende
Unterbrechung angenommen werden
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 33
Konzept der Unterbrechungen IX
Abarbeitung von Unterbrechungen
I
Reihenfolge der Annahme ist exakt festgelegt (i. d. R. durch Prioritäten)
I
nach Unterbrechungsannahme wird Unterbrechungsbehandlung (interrupt
handling) durchgeführt
I
u. a. durch Unterbrechungsbehandlungsprozeduren (interrupt service
routines); sind Teil des Betriebssystems
I
nach Unterbrechungsbehandlung soll i. d. R. an oder nach der
Unterbrechungsstelle fortgefahren werden
Unterbrechung führt zu erzwungenem Unterprogrammaufruf
I
I
I
nicht immer explizit programmiert
nicht immer vorausgeplant
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 34
Konzept der Unterbrechungen X
Unterbrechungsanforderung gesetzt ?
ja
nein
Unterbrechung
erlaubt ?
Unterbrechung
anstehend
nein
ja
Unterbrechung
angenommen
IC und ggf. andere
Register retten
Unterbrechungsinformation laden
IC und ggf. andere
Register laden
neuen Befehlszyklus beginnen
nächsten Befehl ausführen
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 35
Konzept der Unterbrechungen XI
Ablauf bei Unterbrechungsannahme
I
IC, PSW (Prozessorstatuswort) und andere ggf. verwendete Register retten
I
Unterbrechungsinformation laden
I
I
I
I
I
I
bei Unterbrechungsanalyse muss genaue Ursache/Art der Unterbrechung
festgestellt werden können
mit Hilfe der Unterbrechungsinformation wird dann entschieden, welche
Unterroutine aufgerufen wird
mögliche Unterbrechungsinformationsquellen:
Unterbrechungsnummer aus Befehlskodierung ableitbar (z. B. immediater
Operand des Systemaufruf-Befehls)
Unterbrechungsnummer implizit bekannt (welche Unterbrechung wird gerade
angenommen?)
Gerätenummer liegt am Bus an (liefert Unterbrechungsquelle bei externer
Unterbrechung)
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 36
Konzept der Unterbrechungen XII
Ablauf bei Unterbrechungsannahme (Fortsetzung)
I Unterbrechungsinformationen laden
I
I
I
I
I
I
Information über Ursache ist Index in Sprungtabelle
⇒ sog. Tabelle von Unterbrechungsvektoren
liegt oft an fester, bekannter Adresse im Hauptspeicher
besitzt eine Tabellenzeile pro Unterbrechung
liefert Information, wo sich zugehörige Unterbrechungsbehandlungsroutine im
Hautspeicher befindet
IC mit neuer Adresse aus Unterbrechungsvektor und andere ggf. benötigte
Register laden (z.B. verändertes PSW)
(anschließend Einmündung in „normalen Befehlszyklus“)
spezieller Befehl für Rückkehr an die Unterbrechungsstelle inkl. Reinstallation
alter Werte des IC, PSW und anderer ggf. verwendeter Register
I RETURN_FROM_INTERRUPT, RTI
I
Effekt etwa invers zum Ablauf der Unterbrechungsannahme
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 37
Konzept der Unterbrechungen XIII
Ablauf bei Unterbrechungsannahme (Fortsetzung)
I wird Unterbrechung angenommen, dann müssen i. d. R. alle weiteren
Unterbrechungen ausgeschlossen werden
⇒ Modifikation des PSW bzw. UER (Unterbrechungserlaubnisregister)
I u. U. können höher priorisierte Unterbrechungen weiter zugelassen werden
⇒ keller-artige Unterbrechungsbehandlung
I Unterbrechungsbehandlung muss schnell sein
I besonders wichtig bei Echtzeitbetrieb
I Unterbrechungsannahme i. d. R. nur am Ende eines Befehlszyklus möglich
I der der Annahme vorausgehende Befehl kann
I abgeschlossen sein (mit definiertem Effekt) ⇒ häufig bei systembezogenen
I
I
Unterbrechungen
abgebrochen sein (mit undefiniertem Effekt)
unterdrückt sein (ohne Effekt) ⇒ Befehl muss wiederholt werden
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 38
Konzept der Unterbrechungen XIV
Beispielimplementierung des Unterbrechungsmechanismus
I Unterbrechungsanforderungsregister IRR
I
I
zeigt an, welche Unterbrechungen angefordert sind
jedem Unterbrechungsereignis ist ein Bit im IRR zugeordnet
I
I
I
I
I
1 ↔ TRUE : Unterbrechung angefordert
0 ↔ FALSE : Unterbrechung nicht angefordert
Bits im IRR werden von Hardware gesetzt
Bits können von Software zurückgesetzt werden
Unterbrechungserlaubnisregister IER
I
I
zeigt an, welche Unterbrechungen erlaubt sind
jedem Unterbrechungsereignis ist Bit im IER zugeordnet
I
I
I
1 ↔ TRUE : Unterbrechung erlaubt
0 ↔ FALSE : Unterbrechung nicht erlaubt
Bits im IER werden software-mäßig mit privilegiertem Befehl gesetzt
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 39
Konzept der Unterbrechungen XV
Beispielimplementierung des Unterbrechungsmechanismus
I bei Prüfung, ob Unterbrechung angenommen werden soll, werden Inhalte der
Register verglichen
Inhalte der Register verglichen
I
IRR
...
1
...
1
...
0
...
0
...
IER
...
0
...
1
...
1
...
0
...
Beispielcode:
IF SOME itr IN register_bitsize
WHICH IRR[itr] AND IER[itr]
THEN
Unterbrechung itr angenommen;
weitere Aktionen ...;
END;
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 40
Konzept der Unterbrechungen XVI
Besondere Anwendung von Unterbrechungen
I
Spezialbefehle ⇒ Systemaufrufe (system calls)
I
ermöglichen einen Wechsel von nieder- in höherprivilegierten Zustand
I
dadurch wird u. a. ermöglicht, Benutzern Dienste des Betriebssystems
verfügbar zu machen
Befehle dieser Art
I TRAP bei Motorola 680x0
I INT bei Intel 80x86
I SUPERVISOR_CALL (SVC) bei IBM- und Siemens-Systemen
I
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 41
Betriebsarten I
Welche sog. Betriebsarten (processing modes) kann ein Betriebssystem
unterstützen?
Klassifizierungskriterien für Betriebsarten
I
Systemumgebung und ihrer Aufgabenstellung
I
I
I
I
Benutzeranzahl
I
I
I
Stapelbetrieb
interaktiver Betrieb
Echtzeitbetrieb
Einbenutzerbetrieb
Mehrbenutzerbetrieb (Teilnehmerbetrieb)
Eingriffsmöglichkeiten des Benutzers
I
I
Off-Line-Betrieb
On-Line-Betrieb
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 42
Betriebsarten II
Klassifizierungskriterien für Betriebsarten
I
Programmierbarkeit des Systems durch den Benutzer
I
I
I
Programm-/Speicherorganisation
I
I
I
frei programmierbar
nicht programmierbar
Einprogrammbetrieb
Mehrprogrammbetrieb
Programm-/Prozessororganisation
I
Time-Sharing-Betrieb
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 43
Betriebsarten III
Stapelbetrieb
I batch processing
I traditionelle Betriebsart
I gut bei verarbeitungs- und datenintensiven Aufgaben
I
I
Ablauf:
I
I
I
Anforderungen an das System werden zusammenhängend als Auftrag (task)
eingegeben
Abarbeitung „am Stück“ ohne weitere Einflussnahme von außen
mögliche Bestandteile eines Auftrags:
I
I
I
I
Stapelbetrieb soll hohe Auslastung der Komponenten und großen Durchsatz
erreichen
Programme
Daten
Steueranweisungen
Eingaben bei Stapelbetrieb
I
I
früher: Lochkartenstapel
heute: Kommandodatei
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 44
Betriebsarten IV
Interaktiver Betrieb
I interactive processing
I oder: Dialogbetrieb
I Interaktiver Betrieb soll kurze Antwortzeiten (response time) und hohe
Verfügbarkeit gewährleisten.
I Ausführung einer Aufgabe besteht aus Folge von Interaktionszyklen
I
Definition einer Teilaufgabe durch den Benutzer, Antwort des Systems
Folge: Benutzer kann auf Ablauf der Auftragsbearbeitung Einfluss nehmen
Echtzeitbetrieb
I real time processing
I Anwendung
I
I
I
I
I
Steuerung technischer Prozesse
Anforderung
auf asynchron anfallende Daten muss innerhalb eines vorgegebenen
Zeitintervalls reagiert werden
Verspätungen können katastrophale Folgen haben
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 45
Betriebsarten V
Einbenutzerbetrieb
I
single user mode
I
nur ein Benutzer arbeitet mit dem Betriebssystem
I
Beispiele: DOS-Betriebssysteme, (Windows)
Mehrbenutzerbetrieb
I
multi-user mode
I
auch: Teilnehmerbetrieb
I
mehrere Benutzer teilen sich die Betriebsmittel (z. B. Speicher, Festplatte)
I
Beispiele: BS für Großrechner, Unix
Off-Line-Betrieb
I
keine Eingriffsmöglichkeit für Benutzer während der Auftragsbearbeitung
I
Beispiel: Stapelverarbeitung
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 46
Betriebsarten VI
On-Line-Betrieb
I
System ist interaktionsfähig
I
Beispiele: WINDOWS-Betriebssysteme, MAC-OS, Unix
freie Programmierbarkeit
I
user programmable
I
Benutzer darf eigene Programme schreiben und anwenden
I
Beispiel: PC-Betriebssysteme
keine Programmierbarkeit
I
non-programmable
I
Benutzer darf nur bestehende Programme anwenden
I
Beispiele: KFZ-Bereich
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 47
Betriebsarten VII
Einprogrammbetrieb
I
I
I
uniprogramming
es befindet sich maximal ein Benutzerprogramm zur Ausführung im
Hauptspeicher
Beispiel: MS-DOS
Mehrprogrammbetrieb
I
I
I
multiprogramming
es können mehrere ausführbare Benutzerprogramme im Hauptspeicher sein
Beispiele: WINDOWS-Betriebssysteme, Unix, MAC-OS
Time-Sharing-Betrieb
I
I
I
Prozessor arbeitet im Multiplexbetrieb
mehrere Programme werden abwechselnd stückweise ausgeführt
Beispiele: Großrechnerbetriebssysteme, Unix, Windows
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 48
Beispiel
I
Entwurf/Eingabe der Architektur mit SOPC2 Builder
I
Vereinfacht den Entwurfsprozess eines Systems stark
I
Steuerung eines Roboterarms, BS notwendig?
2
system-on-a-programmable-chip
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 49
Zusammenfassung und Ausblick
I
Betriebssysteme I
I
Einführung
I
Unterbrechungen
Nächste Vorlesung behandelt
I
Betriebssysteme II
I
Prozesskonzept, Semaphore
25. Januar 2011 | Technische Universität Darmstadt | Dr.-Ing. Wolfgang Heenes | 50