updatet

Writerside/in.tree

@@ -30,6 +30,10 @@
             <toc-element topic="Prozessorkonzepte.md">
                 <toc-element topic="MU0Rechner.md"/>
                 <toc-element topic="MU1Rechner.md"/>
+                <toc-element topic="MU2-3Rechner.md"/>
+                <toc-element topic="MU4-5Rechner.md"/>
+                <toc-element topic="MU6Rechner.md"/>
+                <toc-element topic="MU7Rechner.md"/>
             </toc-element>
         </toc-element>
     </toc-element>

Writerside/topics/RA/MU1Rechner.md

@@ -182,8 +182,8 @@ _Im Praktikum wird nur erwartet, dass Funktion bekannt ist, nicht bspw FA, FIA,
 - in Din muss oe gesetzt sein, in ACC muss ie gesetzt sein
 - Transport über ALU
   - [ALU Funktion](MU1Rechner.md#grundfunktionen-mu1-alu) muss B sein
-- Da Speicher nicht angesprochen wird (keine [])
-  - [MEMeq=0](MU0Rechner.md#speicher-des-mu0) und [RnW beliebig](MU0Rechner.md#speicher-des-mu0) 
+- Da Speicher nicht angesprochen wird (keine [ ])
+  - [MEMeq=0](MU0Rechner.md#speicher-des-mu0) und [RnW beliebig (laut Rapp lieber 1)](MU0Rechner.md#speicher-des-mu0) 
 
 **Din = [SP]**
 - Inhalt von SP ist Adressinformation
@@ -222,10 +222,10 @@ _Im Praktikum wird nur erwartet, dass Funktion bekannt ist, nicht bspw FA, FIA,
 
 
 ## Die Addition ADD S
-- IR wird zur Adressierung verwender und der Wert nach Din gebracht
+- IR wird zur Adressierung verwendet und der Wert nach Din gebracht
   - **Din = [IR]**
 - Inhalt des AKK wird auf A-Bus gelegt, Inhalt von Din auf B-Bus
-  - [ALU-Funktion](MU1Rechner.md#grundfunktionen-mu1-alu) ist **A+B, S : ACC = ACC + DIN**
+  - [ALU-Funktion](MU1Rechner.md#grundfunktionen-mu1-alu) ist **A+B, S:   ACC = ACC + DIN**
 
 ![image_72.png](image_72.png)
 
@@ -264,7 +264,7 @@ _Im Praktikum wird nur erwartet, dass Funktion bekannt ist, nicht bspw FA, FIA,
 - Beide Befehle weisen 2 Zustände auf
   - unterscheiden sich durch Statusbits des Akkumulators
 - Beide Zustände haben Schrittnummer 1 und Folgeschritt 0
-- Funktion **NOP** ist gekennzeichnet
+- Funktion **NOP** (**N**o **Op**eration) ist gekennzeichnet
   - kein Registerinhalt wird verändert
     - Alle Register haben oe und ie auf 0
   - Speicher wird nicht angesprochen
@@ -295,3 +295,17 @@ _Im Praktikum wird nur erwartet, dass Funktion bekannt ist, nicht bspw FA, FIA,
 - Stack, Unterprogramme
 - Beschreibung der Microcode-Funktion durch einfache Sprache
 - Zentrales Register: ACC → Akkumulator-Architektur
+
+## Probleme des MU1-Designs
+- **Speichergröße**
+  - begrenzt auf 4096 Worte (12Bit) bzw. 65k Worte (16Bit)
+- **Anzahl Befehle**
+  - Begrenzung auf 4 Bit breiten Opcode
+- **Absolute Adressierung**
+- **Adressberechnungen**
+  - Müssen in einem Register zwischengespeichert werden
+- **Nur ein Datenregister**
+- **Berechnung Programmcounter**
+  - Muss jedes Mal durch ALU erhöht werden → verlangsamt Prozessor
+
+## [Weiterentwicklung MU2](MU2-3Rechner.md)

Writerside/topics/RA/MU2-3Rechner.md

@@ -0,0 +1,67 @@
+# MU2 und MU3Rechner
+## MU2 Rechner
+## Adressraum vergrößern
+### Wortbreite vergrößern
+- 16 Bit → 32 Bit
+  - Register, Bus, ALU
+
+### Adressberechnung mit Offset
+- Adresse = Register(bereits vorhandene Adresse) + Offset
+- Offset kann mit weniger Bits angegeben werden
+  - Adresse hat volle Breite
+
+**Wird benötigt für:**
+- **Relative Adressierung** für Unterprogramme / Sprünge
+- **Indizierte Adressierung** für Speicherzugriffe
+  - Wie indirektes Laden und Speichern mit Offset
+- Laden von **PC-relativen Konstanten**
+  - Prozessoren mit fester Befehlsbreite
+    - Nur kleine Konstanten können im Code dekodiert werden
+  - Falls Konstanten in der Nähe des augenblicklichen Programms (_bspw. hinter Returnanweisung eines Unterprogramms_)
+    - können geladen werden
+
+### Relative Adressierung
+- ![image_128.png](image_128.png)
+- Code wird im Speicher verschiebbar
+
+#### Labels
+- Umsetzung von PC-relativen Sprüngen mit Labels
+- ![image_129.png](image_129.png)
+
+### Indizierte Adressierung
+#### Beispiel Stack
+![image_130.png](image_130.png)
+- In Unterprogrammen wird dyn. Speicher reserviert, indem der Stackpointer dekrementiert wird
+- Zugriff auf Speicher über Stack + Offset(in Befehl)
+- PUSH & POP nicht ausreichend
+  - bei mehreren Variablen auf dem Stack jeweils beim Lesen der Stack geräumt werden müsste
+
+### Adressberechnung in der ALU
+- Adresse als Ergebnis der ALU ohne Speicherung in ACC
+- Keine absolute Adressierung (aus IR)
+- Nur ALU schreibt auf Adressbus (ohne Multiplexer)
+- 32 bit
+
+#### Maximale Laufzeit:
+![image_131.png](image_131.png)
+- **Gesamtlaufzeit ist zu lang!**
+- in einem Takt möglich
+  - falls Taktfrequenz niedrig genug
+
+## MU3: Einführung des Adressregisters
+![image_132.png](image_132.png)
+- Ein Takt mehr um Daten aus dem Speicher zu holen
+- Taktfrequenz kann höher sein
+  - Laufzeit pro Teilstück kürzer
+- **Nachteil:**
+  - Nutzen des PC und Inkrementieren geht nicht mehr parallel
+    - in Aout muss vor Fetch eine Kopie des aktuellen PC stehen
+      - _(Fetch beginnt bei Aout!)_
+
+### Beispiel relative Sprünge
+![image_133.png](image_133.png)
+
+## Problem im Fetch-Zyklus
+**Datentransferbefehle ändern Aout**
+
+![image_134.png](image_134.png)

Writerside/topics/RA/MU4-5Rechner.md

@@ -0,0 +1,130 @@
+# MU4 und MU5 Rechner
+## Registeranzahl erhöhen
+### Registerarchitektur
+- Gesamtzahl der Register ist normalerweise eine Zweierpotenz
+  - 8 (ARM-Thumb), 16 (ARM), 32 (Power PC, MIPS) und mehr Register
+  → Ergebnisse von Registern können in einem von n Registern gespeichert werden
+- Manchmal werden Spezialregister (_PC, SP, LR_) wie andere Register adressiert
+  - Vorteil: Werte können in arithmetischen Operationen und zur Adressierung benutzt werden
+  - _ARM: PC in R15, LR in R14, SP in R13_
+
+**Adressierung der Quell- / Zielregister muss im Befehl enthalten sein**
+- Bei 16 Registern ist 4Bit (=n) Adressinformation für QR und ZR nötig
+  - 2-Adress-Befehle (_bspw. add R0, R1 ; R0 += R1_)
+    - brauchen 2n Bits zur Dekodierung
+  - 3 Adress-Befehle (_bspw. add R0, R1, R2 ; R0 = R1+R2_)
+    - brauchen 3n Bits zur Dekodierung
+- Prozessoren mit 16 Bit
+  - 2-Adress-Befehle, wenig Register
+- Prozessoren mit 32 Bit
+  - 3-Adress-Befehle, viele Register
+
+## Konsequenzen aus der Registerarchitektur
+- Gut
+  - Register erlauben schnellere Speicherung von Werten
+  - arithmetische Befehle lassen sich in einem Takt ausführen
+  - Register erlauben indirekten Zugriff auf Variablen
+    - Inhalt eines Registers wird als Adresse genutzt
+      - Registerbreite sollte groß genug für jede Adresse sein
+- Schlecht
+  - Direkter Zugriff funktioniert bei einem Befehlssatz mit gleicher Breite aller Befehle nicht mehr
+  - Laden von Konstanten (Immediate Werte) in ein Register ist schwierig
+    - nur kleine Immediate Werte haben Platz im Befehlscode
+
+## Link-Register für Unterprogrammaufrufe
+- Speichert Rücksprungadresse bei Ausführung eines Unterprogramms
+  - (vorher: Push auf den Stack)
+- Am Ende des UP wird die Adresse wieder in den PC geschoben
+  - (vorher: Pop vom Stack)
+- Erlaubt Unterprogrammaufrufe ohne Speicherung auf Stack
+
+## MU4 mit Registersatz (Übergang von Akkumulator- zur Registerarchitektur)
+![image_135.png](image_135.png)
+- Einfachste Operation (_add r1, r2, r3_) kann nicht erzeugt werden
+  - Registerbank hat nur Zugriff auf A-Bus
+
+**Prozessor funktioniert so noch nicht!**
+
+_Registerbank braucht Zugriff auf A- und B-Bus_
+
+## MU5: Verbesserung des internen Bussystems und Shifter
+![image_136.png](image_136.png)
+- meiste Befehle lassen sich realisieren
+- Jedes Register hat Ausgang auf A- und B-Bus
+- Operanden, die über B-Bus in ALU kommen, können vorher noch geschoben werden
+- Auf B-Bus können kleine Immediate-Werte aus IR in Berechnungen verwendet werden
+- Es werden noch zu viele Takte pro Operation benötigt
+
+- bisher konnten Registerinhalte auf A-Bus gelegt werden, Immediate auf B-Bus
+  - nicht optimal, da arithmetische Operationen zwei Registeroperanden haben
+- Verbesserung, wenn Registerinhalte auf A-Bus und B-Bus gelegt werden können
+
+### Shifter
+- erlaubt es Operanden des B-Bus vor der Verarbeitung nochmal zu schieben
+  - Wichtig für Adressberechnungen
+    - häufig ein Wortoffset in eine Adresse auf Byte-Basis umgewandelt
+
+## MU5: Verbesserte ALU
+![image_137.png](image_137.png)
+- Einsatz von Modifikatoren
+  - Kann Eingang durchschalten
+  - Kann alle Bits auf 0 / 1 setzen
+- Einsatz eines Shifters
+  - Kann Wert um Shiftweite nach links / rechts schieben
+  - Kann Rotation durchführen
+- Weitere Funktionen der ALU
+  - Neben **A+B, A-B, A+B+1**
+  - **A AND B**
+  - **A OR B**
+  - **NOT A**
+  - **NOT B**
+  - **A XOR B**
+
+## MU5 Fetch-Zyklus
+![image_138.png](image_138.png)
+- in Aout muss Kopie von PC stehen
+  - vorheriger Befehl muss sicherstellen, dass das gegeben ist
+    - Insbesondere Datentransfer-Befehle
+
+## Arithmetische Operationen
+![image_139.png](image_139.png)
+- brauchen ein Taktzyklus + Fetch
+
+## Datentransfer
+![image_140.png](image_140.png)
+
+## Steuermatrix des MU5
+![image_141.png](image_141.png)
+![image_142.png](image_142.png)
+
+## Vergleich MU5 - ARM-Design
+- Datenverarbeitungsbefehle können wie bei ARM in einem Takt durchgeführt werden
+- Datentransferbefehle
+  - MU5: 3 Takte
+  - ARM: 2 Takte
+    - Dout-Register gibt Informationen direkt an Speicher
+    - Din braucht auch keinen Takt Verzögerung
+- ARM-Prozessor
+  - Kann Daten über Din direkt in Registerbank zu schreiben
+    - sonst wären einige Adressierungsarten nicht möglich
+
+## MU5a
+### Verbesserte Adressberechnung und Umstellung der Speicheradressierung
+![image_143.png](image_143.png)
+
+#### Optimierung der Speicheradressierung
+- 32 Bit → Register, Bus, ALU
+- Speicher bisher wortweise
+  - verbraucht für kleine Datenwerte viel Speicher
+- Umstellung auf byteweise Adressierung erlaubt Einführung neuer Befehle für Adressierung von Halbwörtern
+- zusätzlicher Incrementer für Register mit Speicheradressen
+  - effiziente Inkrementierung um 2 oder 4
+
+![image_144.png](image_144.png)
+
+#### Speicheradressierung
+![image_145.png](image_145.png)
+![image_146.png](image_146.png)
+
+> AB 01 CD 23 steht im Speicher als 23 CD 01 AB
+

Writerside/topics/RA/MU6Rechner.md

@@ -0,0 +1,29 @@
+# MU6-Rechner
+## Harvard-Architektur
+- Trennung von Daten und Befehlsbus
+  - In einem Takt können Daten geholt/geschrieben und ein Befehl geholt werden
+  - Durchsatz wird deutlich erhöht
+- Adressregister erhält einen Addierer, um Blocktransfers von Daten zu ermöglichen
+- Zurückschreiben der letzten Adresse in ein Register erfordert Zugriff auf C-Bus
+
+## Vergleich Harvard- / [Von-Neumann-Architektur](Prozessorkonzepte.md#von-neumann-rechner-speicherprogrammierter-rechner)
+
+| Harvard                                                   | Von Neumann                            |
+|-----------------------------------------------------------|----------------------------------------|
+| je ein Befehls- und Datenbus                              | Nur ein Bus für Befehle und Daten      |
+| schnellerer gleichzeitiger Zugriff auf Programm und Daten | Kein Programm Fetch bei Datenzugriffen |
+| ![image_149.png](image_149.png)                           | ![image_150.png](image_150.png)        |
+
+## Datenpfad mit Harvard-Architektur
+![image_151.png](image_151.png)
+- Barrelshift-Einheit der ARM-Prozessoren im B-Bus hier nicht eingezeichnet
+
+## MU6-Architektur
+- Wichtigste Änderung: Trennung von Instruktions- und Datenspeicher
+- Da PC immer Instruktionsadresse vorgibt
+  - PC und Instruktions-Adressregister sind identisch
+  - PC taucht im Registerfile noch auf
+    - sein Wert kann auf A- / B-Bus gelegt werden
+- Werte im Instruktionregister können für [ALU-Operationen](MU4-5Rechner.md#mu5-verbesserte-alu) verwendet werden
+- Man könnte Takte sparen
+  - WENN Dout und Din nicht Register, sondern ein direkter Zugriff möglich

Writerside/topics/RA/MU7Rechner.md

@@ -0,0 +1,50 @@
+# MU7-Rechner
+## Pipeline
+- erlaubt den nächsten Befehl zu holen während der letzte noch bearbeitet wird
+- für Implementierung notwendig:
+  - Ergebnisse jeder Pipelinestufe in Zwischenregistern speichern
+    - Stufen werden unabhängig voneinander
+    - Stufen können gleichzeitig arbeiten
+- Für jede Stufe eigenes Instruktionsregister
+  - steuert Abarbeitung des jeweiligen Befehls
+- Sprungbefehle führen zu äußerem Eingriff in den Ablauf der Pipelinestufen
+  - kann Ausführung der jeweiligen Operation verhindern
+- **Moderne Pipelines:**
+  - Pipelines mit 5-17 Stufen
+  - längere Bearbeitung von Floatingpoint-Befehlen → lange Pipelines
+
+## Datenpfad mit 5-Stufen Pipeline
+![image_152.png](image_152.png)
+
+## Pipeline 6-stufig
+![image_153.png](image_153.png)
+
+- **fetch**: nächsten Befehl aus Speicher holen
+- **dec**: Befehl dekodieren (Befehlsart ermitteln)
+- **reg**: Operanden aus Registerbank holen
+- **ALU**: ALU Berechnung / Speicheradresse berechnen
+- **mem**: Zugriff auf Speicher
+- **res**: Ergebnis in Registerbank zurückschreiben
+
+## Pipeline-Hazard durch Registerzugriff
+read after write Hazard
+
+![image_154.png](image_154.png)
+
+## Nachteil der Pipeline: Sprungbefehle
+- Sprungbefehle brauchen 5 Takte zusätzlich um nächste gültige Instruktion auszuführen
+  - alle Befehle in der Pipeline müssen verworfen werden
+- Ausweg: **Forwarding**
+  - Nach Berechnung der neuen Sprungadresse
+    - Direkt in IADR Register/PC schreiben
+  - nur noch 3 Leertakte
+  - ist in allen modernen Prozessoren vorhanden
+
+
+## Pipeline-Hazard durch Sprungbefehl
+Sprungverhalten einer Pipeline mit Forwarding
+
+![image_155.png](image_155.png)
+
+## Datenpfad mit 5-Stufen Pipeline und Forwarding des PC
+![image_156.png](image_156.png)

Writerside/topics/RA/Prozessorkonzepte.md

@@ -26,4 +26,8 @@ Veröffentlicht 1945
 
 ## MU0 - MU7
 ### [MU0 - Rechner: Basiskonzept](MU0Rechner.md)
-### [MU1 - Rechner](MU1Rechner.md)
+### [MU1 - Rechner: kompletter Rechner](MU1Rechner.md)
+### [MU2/3 - Rechner](MU2-3Rechner.md)
+### [MU4/5 - Rechner: Adressberechnung, Register-Architektur, Load-Store](MU4-5Rechner.md)
+### [MU6 - Rechner: Harvard-Design](MU6Rechner.md)
+### [MU7 - Rechner: Pipelining](MU7Rechner.md)