Shorter lecture names

4 files changed, 99 insertions, 0 deletions

diff --git a/ws2015/oss/blaetter/01/abgabe.md b/ws2015/oss/blaetter/01/abgabe.md
new file mode 100644
index 0000000..405ab62
--- /dev/null
+++ b/ws2015/oss/blaetter/01/abgabe.md
@@ -0,0 +1,27 @@
+# Aufgabe 4 -- Realisierung von Unterprogrammen
+
+a)
+    - Code duplication -- Etwaige spätere Änderungen müssen manuell an alle Stellen kopiert werden.
+    - Argumente müssen manuell an jede Stelle eingepflegt werden.
+b) Die Kosten der Befehle für das Springen ins Unterprogramm und das kopieren der Argumente/Return-Values können groß sein gegen die Kosten des Unterprogramms.
+c)
+    - Die Parameter können auf den Stack gepusht werden, bevor in das Unterprogramm gesprungen wird.
+    - Manche Maschinen bieten spezielle Register für diesen Zweck.
+d) Während der Ausführung unterhält die Maschine ein Register, das die Adresse des nächsten auszuführenden Befehls enthält.
+   Diese kann beliebig überschrieben werden.
+e)
+    `JMP`
+    ~ überschreibt nur das Adress-Register.
+    
+    `CALL`
+    ~ speichert vor dem Überschreiben des Adressregisters noch eine Adresse an die, nach Ausführung des Unterprogramms, in das gesprungen wird, zurückgesprungen werden soll.
+f) `RET` muss so implementiert werden, dass es die Rücksprungadresse aus dem selben Register zu lesen versucht, in das `CALL` sie speichert.
+   `CALL` speichert die Adresse entweder in einem speziellen Register oder auf dem Stack.
+
+# Aufgabe 5 -- Das Betriebssystem
+
+a) $2^n \cdot m~\text{Byte}$
+b) Maschinensprache
+c) Textverabeitung
+d) Gerätetreiber
+e) offene
diff --git a/ws2015/oss/blaetter/02/abgabe.md b/ws2015/oss/blaetter/02/abgabe.md
new file mode 100644
index 0000000..adf72ce
--- /dev/null
+++ b/ws2015/oss/blaetter/02/abgabe.md
@@ -0,0 +1,21 @@
+# Aufgabe 9 -- Multiprogramming
+
+a)
+    Unter Multiprogramming versteht man die Praxis den Prozessor der Maschine mit
+    hoher Frequenz zwischen mehreren auszuführenden Prozessen hin- und herschalten
+    zu lassen.
+b)
+    Die Resourcennutzung kann im Normalfall (viele jeweils wenig CPU-Intensive
+    Prozesse) verbessert werden.
+c) 
+    Prozesse können echt parallel ausgeführt werden (im Idealfall wird also die
+    CPU-Leistung vervielfacht), es ist jedoch komplexes Scheduling erforderlich
+    und Kontextwechsel kann teuer sein.
+
+# Aufgabe 10 -- Programme und Unterprogramme
+
+a) Systemaufrufe (Syscalls)
+b) rekursiv
+c) Endadresse des Unterprogramms
+d) (iii)
+e) Clientanwendung
diff --git a/ws2015/oss/blaetter/03/abgabe.md b/ws2015/oss/blaetter/03/abgabe.md
new file mode 100644
index 0000000..3e6b599
--- /dev/null
+++ b/ws2015/oss/blaetter/03/abgabe.md
@@ -0,0 +1,13 @@
+# E/A-Operationen mit Hilfe von Interrupts
+
+a) Interrupts sind Befehle an die CPU, die einen Sprung in den entsprechenden Handler des Betriebssystems verursachen und von externen Quellen ausgelöst werden (Uhr, E/A Peripherie, …)
+b) Alternativ zu Interrupt-basiertem E/A könnten Geräte auch ihren aktuellen Status auf eine Abfrage des aktuellen Prozesses hin zur verfügung stellen.
+c) Aktives Polling würde effektiv Prozesszyklen verschwenden jedoch den Prozessfluss deterministischer gestalten.
+
+# Einführung in Betriebssysteme
+
+a) Statusbus
+b) `(0,0,0,0)`
+c) PC (Program Counter)
+d) Das Nutzerprogramm bleibt blockiert, bis die E/A-Operation abgeschlossen ist.
+e) `div $t0,$t1,$t2`
diff --git a/ws2015/oss/blaetter/04/abgabe.md b/ws2015/oss/blaetter/04/abgabe.md
new file mode 100644
index 0000000..94578c5
--- /dev/null
+++ b/ws2015/oss/blaetter/04/abgabe.md
@@ -0,0 +1,38 @@
+# 5-Zustands-Prozessmodell
+
+a)
+        i) Übergang von *blocked* zu *running* wird nur via *ready* realisiert, da der Scheduler bereits periodisch Prozesse aus *ready* aufweckt.
+                Zusätzlich auch noch den jeweiligen Prozess aufzuwecken wäre schlicht unnötig.
+        ii) Fordert ein Prozess E/A-Resourcen an, so wird er nach *blocked* verschoben bis die jeweilige E/A-Operation per Unterbrechung bekannt macht, dass der Vorgang abgeschlossen ist.
+        iii) Ein Prozess, der nicht läuft, kann keine E/A-Resource anfordern.  
+b)
+        (i) *new* → *ready*
+                ~ Ein Nutzer hat seine Shell angewiesen `Hello World!` auszugeben, diese forkt um später `/bin/echo` aufzurufen.
+                        
+                *ready* → *running*
+                ~ Der Shell-Prozess ruft `wait` auf den soeben gespawnten Prozess auf und wird daher *blocked*.
+                Der Scheduler entscheidet nun zum Kindprozess zu wechseln.
+
+            *running* → *ready*
+                ~ `/bin/echo` hat nicht innerhalb der switching-Frequenz des Schedulers terminiert.
+                Der Scheduler verschiebt `/bin/echo` in *ready* und wechselt zu einem anderen Prozess.
+
+                *running* → *blocked*
+                ~ `/bin/echo` ist dynamisch gelinkt und möchte eine library von der Festplatte lesen.
+                Es setzt einen Syscall ab und wartet auf das Ergebnis.
+
+            *blocked* → *ready*
+                ~ Die Festplatte fängt an einen Stream von bytes zu schicken.
+                Der Scheduler fängt die Unterbrechung ab und verschiebt `/bin/echo` nach *ready*
+
+            *running* → *exit*
+            ~ `/bin/echo` terminiert.
+        (ii) *new*. Prozesse werden im reinen batch-betrieb nicht dynamisch erzeugt.
+
+# Prozesse
+
+a) Kontext
+b) Uniprogramming
+c) 13.3 min
+d) `fork`
+e) Scheduler