diff --git a/HA3-Rechnerarchitekturen/aufgabe14.md b/HA3-Rechnerarchitekturen/aufgabe14.md
index 2f63e2aae628a0f8db6221e5f68c854e81722a93..88737bb4a640c0bf015d473335192ad25a6ad754 100644
--- a/HA3-Rechnerarchitekturen/aufgabe14.md
+++ b/HA3-Rechnerarchitekturen/aufgabe14.md
@@ -2,7 +2,7 @@
 
 1. **Kollisionen und Wartezeiten**: Wenn sowohl Daten als auch Befehle denselben Bus verwenden, können Kollisionen auftreten, was zu Wartezeiten führt, da der Bus immer nur von einer Einheit zur gleichen Zeit verwendet werden kann.
 
-2. **Performance-Probleme**: Der gemeinsame Bus kann ein Engpass werden, wenn viele Zugriffe auf Daten und Befehle gleichzeitig stattfinden. Dies kann die Gesamtleistung des Systems beeinträchtigen, da die CPU auf den Zugriff auf den Bus warten muss.
+2. **Performance-Probleme**: Der gemeinsame Bus kann zu einem Engpass werden, wenn viele Zugriffe auf Daten und Befehle gleichzeitig stattfinden. Dies kann die Gesamtleistung des Systems beeinträchtigen, da die CPU auf den Zugriff auf den Bus warten muss.
 
 3. **Komplexität des Designs**: Das Design von Steuerlogik wird komplexer, da Mechanismen zur Verwaltung und Priorisierung der Zugriffe auf den Bus erforderlich sind. Dies erhöht die Komplexität und die Kosten der Hardware.
 
@@ -10,7 +10,7 @@
 
 5. **Sicherheitsrisiken**: Die gemeinsame Nutzung eines Busses kann Sicherheitsrisiken erhöhen, da Daten und Befehle potenziell von nicht autorisierten Einheiten abgefangen oder manipuliert werden können.
 
-Durch die Trennung von Daten- und Befehlsbussen (wie im Harvard-Architekturmodell) können diese Nachteile minimiert werden. Dies führt zu einer besseren Systemleistung und erhöht die Effizienz und Sicherheit des Datenverarbeitungsprozesses.
+Durch die Trennung von Daten- und Befehlsbussen können diese Nachteile minimiert werden. Dies führt zu einer besseren Systemleistung und erhöht die Effizienz und Sicherheit des Datenverarbeitungsprozesses.
 
 # Aufgabe 4.1 b)
 
@@ -30,14 +30,13 @@ Durch die Trennung von Daten- und Befehlsbussen (wie im Harvard-Architekturmodel
 1. **Jump (JMP)**:
    - Springt immer zu einer angegebenen Adresse, unabhängig von vorherigen Operationsergebnissen.
 
-## Kontrollstrukturen, die damit umgesetzt werden können
+### Kontrollstrukturen, die damit umgesetzt werden können:
 
 1. **Verzweigungen (if-else)**:
    - Durch bedingte Sprünge wie JZ, JNZ, JG, JL können Verzweigungen implementiert werden. Zum Beispiel:
      ```
      CMP AX, BX     ; Vergleiche AX und BX
      JZ  label_equal   ; Springe zu label_equal, wenn AX gleich BX ist
-     ; Weiterer Code für den Fall, wenn AX und BX nicht gleich sind
      JMP end_label  ; Springe am Ende der bedingten Verzweigung
      label_equal:
      ; Code, der ausgeführt wird, wenn AX und BX gleich sind
@@ -50,8 +49,7 @@ Durch die Trennung von Daten- und Befehlsbussen (wie im Harvard-Architekturmodel
      MOV CX, 10      ; Initialisierung der Schleifenvariable
      loop_start:
      CMP CX, 0       ; Bedingung prüfen
-     JZ loop_end     ; Schleife beenden, wenn CX gleich null ist
-     ; Code innerhalb der Schleife
+     JZ loop_end     ; Schleife beenden, wenn CX gleich null ist (Code innerhalb der Schleife)
      DEC CX          ; Schleifenvariable dekrementieren
      JMP loop_start  ; Springe zum Schleifenanfang
      loop_end: