\item Alle Sprünge, deren Adressen im Indexteil übereinstimmen, werden derselben Zelle im branch prediction buffer zugeordnet. Überprüfung mittels tags, ob es der richtige Eintrag ist.
\item Allgemein: Fehlerrate von 1-Bit Prädiktor ist für Sprünge in Schleifenkonstrukten doppelt so hoch wie die Anzahl ausgeführter Sprünge
\end{itemize*}
\paragraph{ 2 Bit Vorhersagen}
\begin{itemize*}
\item Änderung der Vorhersage nur, wenn 2 falsche Vorhersagen in Folge
\item 2-Bit Branch-Prediction Buffer: Speicherung der Historie, Befehlsadressen als Zugriffsschlüssel
\end{itemize*}
% !{Sprungvorhersage; Quelle RA2 Vorlesung 2020/21](Assets/RA2_Sprungvorhersage.png)
\paragraph{ n-Bit Prädikator}
\begin{itemize*}
\item Verwendet n-Bit Zähler
\item Sättigungsarithmetik (kein wrap around bei Überlauf)
\item Wenn Zähler größer als Hälfte des Maximums $(2^{n-1})$: Vorhersagen, dass Sprung ausgeführt wird; ansonsten vorhersagen, dass Sprung nicht genommen wird
\item Zähler wird bei ausgeführtem Sprung inkrementiert und bei nicht ausgeführtem dekrementiert
\item Instruction Pre-fetch: Insbes. um mehrere Befehle pro Takt liefern (und später ausgeben) zu können, läuft Befehlsholen weiterer Dekodierung voraus (= pre-fetch)
\item Zugriff auf Befehlsspeicher: Bei mehreren Befehlen pro Takt mehrere Zugriffe erforderlich (bei Cache auf ggfs. mehrere cache lines). Werden hier koordiniert/geplant
\item Befehlspuffer: Befehle können hier (lokal im Prozessor!) von Issue-Stufe nach Bedarf abgerufen werden
\end{itemize*}
\paragraph{ Vorhersage von Rücksprungadressen}
Allgemeines Ziel: Vorhersage indirekter Sprünge (d.h. bzgl. Basisadresse in Register)
\begin{itemize*}
\item Hauptverwendung: Rückkehr aus Prozeduraufrufen
\item MIPS: Prozeduraufruf per jal proc, Rückkehr per jr \$31
\item Vorhersage mit branch target buffer schlecht, da Aufruf aus unterschiedlichen Codeteilen heraus möglich
\item Methode: (Stack-) Speicher für Rücksprungadressen
\item Push bei Prozeduraufruf (call), und
\item Pop bei Rücksprung (return)
\item Vorhersagequalität „perfekt“, wenn Stack-Puffer größer als maximale Aufruftiefe
\item Jeder Befehl, der aus der Instruction fetch-Einheit kommt, durchläuft das Scoreboard (Scoreboarding)
\item Wenn für Befehl alle Daten/Operanden bekannt sind und Ausführungseinheit frei ist, wird Befehl gestartet
\item Alle Ausführungseinheiten melden abgeschlossene Berechnungen dem Scoreboard
\item Scoreboard erteilt Befehlen die Berechtigung zum Abspeichern von Ergebnissen, sofern Speichereinheit frei ist und Antidaten- und Ausgabeabhängigkeiten berücksichtigt sind und prüft, ob dadurch neue Befehle ausführbereit werd
\item Zufallsverfahren: Hier wird der zu ersetzende Block innerhalb des Satzes zufällig ausgewählt.
\item FIFO-Verfahren: Beim FIFO-Verfahren (engl. First In, First Out) wird der älteste Block ersetzt, auch wenn auf diesem gerade erst noch zugegriffen wurde
\item LRU-Verfahren (least recently used ) Block ersetzt, auf den am längsten nicht mehr zugegriffen wurde
\item LFU-Verfahren (least frequently used ) am seltensten gelesene Block ersetzt
\item CLOCK-Verfahren: alle Platzierungen im Kreis auf einem Ziffernblatt angeordnet. Ein Zeiger wird im Uhrzeigersinn weiterbewegt und zeigt den zu ersetzenden Eintrag an.
\item Rückschreiben erfolgt erst, wenn Cache-Zeile bei Miss verdrängt wird
\item Funktioniert auch bei großen Geschwindigkeitsunterschieden zwischen Cache und Speicher. Vorkehrungen erforderlich, damit keine veralteten Werte aus dem Speicher kopiert werden.
\end{itemize*}
% !{Write Trough vs Write Back; Quelle RA2 Vorlesung 2020/21](Assets/RA2_cache-write-trough-vs-back.png)
Trefferquote $T=\frac{N_C}{N_G}$ mit $N_G$ Gesamtzahl der Zugriffe auf Speicher und $N_C$ Anzahl der Zugriffe mit Hit auf Cache
\subsection{ Digital-Signal-Prozessoren}
Entwickelt für hohe Leistung, u.a. sich wiederholende, numerisch intensive Aufgaben.
In einem Befehlszyklus kann man ausführen:
\begin{itemize*}
\item eine oder mehrere MAC-Operationen
\item ein oder mehrere Speicherzugriffe
\item spezielle Unterstützung für effiziente Schleifen
\end{itemize*}
Die Hardware enthält:
\begin{itemize*}
\item Eine oder mehrere MAC-Einheiten
\item On-Chip- und Off-Chip-Speicher mit mehreren Ports
\item Mehrere On-Chip-Busse
\item Adressgenerierungseinheit, die auf DSP-Anwendungen zugeschnittene Adressierungsmodi unterstützt
\item Write Invalidate: Das Verändern eines Blocks im Speicher führt zur Invalidierung aller Cache-Kopien mit der gleichen Adresse
\item Write Update / Write Broadcast: Das Verändern eines Blocks im Speicher führt zur Modifikation aller anderen Cache-Blöcke mit der gleichen Adresse
\item (exclusive) Modified: Cache-Block wurde lokal geändert, die Kopie im Hauptspeicher ist ungültig. Will ein anderer Prozessor dieses Datum im Hauptspeicher lesen, so muss der Cache-Block erst in den Hauptspeicher zurückgeschrieben werden.
\item Exclusive (unmodified): Dieser Cache ist der einzige, der den Cache-Block enthält, Wert im Hauptspeicher ist gültig. Liest ein anderer Prozessor dieses Datum im Hauptspeicher, so muss die Zeile als shared markiert werden. Wird das Datum im Hauptspeicher verändert, ist der Cache-Block auf invalid zu setzen.
\item Shared (unmodified): Mehrere Caches (mind. 2) enthalten dieses Datum. Da alle bisher nur gelesen haben, ist das Datum im Hauptspeicher gültig. Schreibzugriffe auf einen shared Cache-Block müssen immer zu einer Bus-Operation führen, damit die Cache-Blocks der anderen Caches auf invalid gesetzt werden können.
\item Invalid: Cache-Block ist noch gar nicht geladen bzw. veraltet/ungültig
\end{itemize*}
Bus-Operationen
\begin{itemize*}
\item Bus Read: wenn ein Prozessor Wert eines Speicherblocks lesen will
\item Bus Read Exclusive: wenn ein Prozessor Wert eines Speicherblocks überschreiben will
\item Flush: wenn ein Prozessor $P_i$ einen Speicherblock alleinig in seinem Cache hat, ein anderer Prozessor $P_j$ aber lesend oder schreibend auf diesen Block zugreift. Bei einer Flush-Operation legt $P_i$ ebenfalls das Datum des Speicherblocks auf den Bus.
\end{itemize*}
Steuersignale
\begin{itemize*}
\item Invalidate-Signal: Invalidieren des Blocks in den Caches anderer Prozessoren
\item Shared-Signal: Signalisierung, ob ein zu ladendes Datum bereits als Kopie im Cache vorhanden ist
\item Retry-Signal: Aufforderung von Prozessor $P_i$ an Prozessor $P_j$, das Laden eines Datums vom Hauptspeicher abzubrechen, da der Hauptspeicher noch ein altes, ungültiges Datum besitzt und vorher aktualisiert werden muss. Das Laden durch $P_j$ kann danach wiederholt werden.
\end{itemize*}
Bewertung von Snooping-Protokollen
\begin{itemize*}
\item Leichte Implementierbarkeit bei Bus-basierten Shared Memory Systemen
\item Snooping skaliert bei Bussen jedoch nicht
\item Bei vielen beteiligten Prozessoren sinkt die effektive Bandbreite des Busses, da überproportional viele Invalidierungsnachrichten per Broadcast über den Bus gehen
\item Punkt-zu-Punkt Netzwerke sind skalierbar, jedoch ist die Implementierung von Broadcasts hier aufwändig
\item Für Snooping-Protokolle daher oft ungeeignet
\item Presence Flag Vector: Im Hauptspeicher abgelegter Bit-Vektor für jeden einzelnen Speicherblock (1 Bit pro Prozessor/Cache + Statusbits (dirty, modified))
\subsection{CISC - complex instruction set Computer}
\begin{itemize*}
\item einfache und komplexe Befehle
\item heterogener Befehlssatz
\item verschiedene Taktanzahl pro Befehl
\item viele Befehlscodeformate mit unterschiedlicher Länge
\item Mikroprogrammwerk - Makrobefehl durch Mikrobefehlsfolge
\item vermischung von Verarbeitungs- und Speicherbefehlen
\end{itemize*}
\subsection{RISC - reduced instruction set computer}
\begin{itemize*}
\item nur einfache Befehle
\item ortohonaler Befehlssatz
\item meist 1 Takt pro Befehl
\item wenige Befehlscodeformate mit einheitlicher Länge
\item Direktverdrahtung
\item Trennung von Verarbeitungs- und Speicherbefehlen
\end{itemize*}
\subsection{Pipeline Prozessoren}
\begin{itemize*}
\item Aufteilung eines Befehls in Teilbefehle
\item parallele Abarbeitung verschiedener Teilbefehle von unerschiedlichen Befehlen möglich
\item Probleme
\begin{itemize*}
\item bedingte Sprünge (unvorhergesehen)
\item LSG: Pipeline um 2 Schritte verzögern
\item LSG: Sprungzielspekulation
\item Datenabhängigkeit
\item LSG: Pipeline um 2 Schritte verzögern
\item LSG: Out-of-Order Prinzip nutzen
\item LSG: Forwarding Hardware
\end{itemize*}
\item Superpipelining - noch mehr Befehlsaufteilung
\end{itemize*}
\subsection{Out-of-Order Architektur}
\begin{itemize*}
\item statt Pipeline bei Datenabhängigen Befehlen um 2 Schritte verzögern, datenunabhängige Befehle einschieben
\item möglichst ständige Auslastung aller EX Einheiten
\end{itemize*}
\subsection{Skalare Prozessoren}
\begin{itemize*}
\item Mikroarchitektur
\item Befehlszuordnung und Konfliktvermeidung geschieht durch Hardware
\item Speicherzugriffe automatisch von Load/Store Einheit
\item ein Befehlsstrom mit einfachem Befehl an Ausführungseinheit
\item bessere Reaktion auf Laufzeitereignisse
\item Spekulation möglich
\item Superskalar ($\geq2$ EX Einheiten)
\begin{itemize*}
\item Befehle in Befehlsfenster gespeichert
\item Zuordnungseinheit wählt Befehl aus, die parallel verarbeitet werden können
\end{itemize*}
\end{itemize*}
\subsection{VLIW Architektur (very long instruction word)}
\begin{itemize*}
\item Befehlszuordnung und Konfliktvermeidung geschieht durch Compiler
\item Compiler muss Zeitbedarf der Speicherzugriffe in Befehlsplanung einbeziehen
\item Befehlsstrom mit Tupel von Befehlen
\item nicht un-flexibel bei Reaktion auf Laufzeitereignisse
\item VLIW hat festes Befehlsformat; höhere Codedichte
\item Vorteilhaft bei gut parallelisierbarem Code
\item Forwarding Hardware - nach dem EX werden Daten in Pufferregister gespeichert und können vom nächsten Befehl schon genutzt werden
\item WB erfolgt erst darauf
\item Datenabhängigkeitsproblem wird verringert
\item MUX nutzt eher Pufferdaten als Registerdaten
\end{itemize*}
\section{Speicherarchitekturen}
\subsection{Adresspipelining}
\begin{itemize*}
\item Aufteilen des Speicherzugriffs in mehrere Phasen
\item parallele gestaffelte Abarbeitung dieser Phasen für mehrere Speicherzugriffe
\item Adresse auslesen/dekodieren; Daten mit Prozessor
\end{itemize*}
\subsection{Speicher Interlacing}
\begin{itemize*}
\item Speicheraufteilung in mehrere physische Bände
\item Adressen nicht kontinuierlich in den Bänden, sondern wechseln von Band zu Band
\item nahezu gleichzeitiges Benutzen der Daten möglich (Daten-/Adressbus verhindern Parallelität)
\end{itemize*}
\subsection{Burst Mode}
\begin{itemize*}
\item Prozessor gibt eine Adresse, Speicher liefert n Datenworte (Adr, Adr+1,..., Adr+n-1)
\item falls folgende Datenworte genutzt werden, war für n Datenworte nur 1 Speicherzugriff (Zeit) nötig
\end{itemize*}
\subsection{Cache Speicher}
\begin{itemize*}
\item kleinder, schneller Prozessornaher Speicher
\item CPU weiß nciht dass Cache zwischengeschaltet ist
\item es wird immer zuerst im Cache nachgeschaut, zum Adressvergleich (kostet Zeit)
\item Cache besteht aus Cache Tabelle
\begin{itemize*}
\item voll assoziativ - Adressvergl. der kompletten Adresse
\item jede beliebige Adressfolge im Cache möglich
\item kann zu langsamen Adressvergleich führen
\item direct-mapped Adressvergleich nur über Teiladresse - eine Tabelle im Cache
\item mehr-wege-assoziativ Cache - mehrere Adressvergleiche parallel
\end{itemize*}
\item Schreibstategien (bei prozessor WB)
\begin{itemize*}
\item Write Trough Daten werden sowohl im Cache als auch im Hauptspeicher aktualisiert
\item Write Back: Cache sammelt Schreibvorgänge und aktualisiert nur im Cache. Nach einer entsprechenden Anweisung werden Daten in den hauptspeicher kopiert (aktualisiert)
\end{itemize*}
\item (über) Schreibstategien
\begin{itemize*}
\item nach Anlaufphase ist Cache immer vollständig gefüllt
\item für neue Einträge Ersetzungsstrategien benötigt FIFO, least recetly used - durch Zusatzhardware
\end{itemize*}
\item Speicherverwaltung mit memory management günstiger vor dem Cache
\end{itemize*}
\section{Parallele Rechnerarchitekturen}
\subsection{Flynn}
\begin{description*}
\item[SISD] Single Instruction Single Data
\item[SIMD] Single Instruction Multiple Data
\item[MIMD] Multiple Instruction Multiple Data
\item[MISD] Multiple Instruction Single Data
\end{description*}
\subsection{MIMD Kopplung}
\begin{description*}
\item[enge K.] (shared memory)
\begin{itemize*}
\item parallelzugriff in Datenbreite des Prozessors
