\newpage

%-------------------------------------
%               MAX
%-------------------------------------

\section{De Processor}

\subsectionauthor[Max Höfelmann]{Introductie}
Dit hoofdstuk bevat een uitleg van de principes en technieken die gebruikt worden in het implementeren van een processor. Het grootste gedeelte zal gaan over een meer realistische implementatie van pijplijnen in MIPS, met daarbij nog een deel over de meer complexe benodigdheden voor het implementeren van moeilijkere instructie sets zoals x86.

We gaan onderzoek over een subset van de MIPS kern instructies: \begin{itemize}
\item De geheugen instructies \textbf{load word} (lw) en \textbf{store word} (sw).
\item De arithmetisch-logische instructies add, sub, AND, OR en slt.
\item De instructies \textbf{branch equal} (beq) en \textbf{jump} (j), deze zullen als laatst worden toegevoegd.
\end{itemize}
Tijdens het onderzoeken van deze instructies zullen we zien hoe verschillende aanpakken de \textbf{clock rate} en \textbf{CPI} zullen aanpassen. We zullen zien dat eenvoud houd van regelmaat. 

Voor elke instructie zijn de eerste twee stappen indentiek: 

\begin{enumerate}
\item Stuur de programma teller naar het geheugen dat de code bevat en haal de instructie van dat geheugen.
\item Lees een of twee registers afhankelijk van welke registers er worden vermeld in de instructie. Voor de lw instructie hoeven we maar een register te lezen maar de meeste andere intructies vragen voor twee registers.
\end{enumerate}

Na deze twee stappen ligt het aan de instructie klasse welke actie er nodig is om de instructie te volbrengen. Gelukkig zijn voor elk van de drie instructie klasse (\textbf{memory-reference, arithmetic-logical en branches}) de acties grootendeels hetzelfde. In figuur 4.1.1 zien we een hoger-niveau van de MIPS implementatie, gefocussed op de verschillende functionele gedeeltes en hun connecties.
 
\includegraphics[width=\textwidth]{f4_1_1}
 
Op verschillende plekken is te zien dat een enkele input kan komen van meerdere sources zoals bij de PC er meerdere ADD's leiden naar de input lijn van de PC. In de praktijk kan dit niet zo simpel en zullen er logic elementen geinstalleerd moeten worden om de juiste source te kiezen. Zo'n logic element wordt vaak een \textbf{multiplexor} genoemd of nog beter een \textbf{data selector}. In figuur 4.1.2 zijn de 3 benodigde multiplexoren en de daarbijhorende datapaden toegevoegd aan figuur 4.1.1. De toegevoegde control unit, die instructies als input heeft, wordt gebruikt om te bepalen hoe de control lijnen voor de eerste twee multiplexoren lopen. De derde multiplexor, die bepaald of de PC + 4 of het bestemming adres wordt opgeslagen in PC, werkt op basis van de ALU output

\includegraphics[width=\textwidth]{f4_1_2}
 
\subsectionauthor[Max Höfelmann]{Logica-ontwerp Verbeteringen}
 De datapad elementen in MIPS bestaan uit twee verschillende types: elementen die werken via data waardes en elementen die een staat bevatten. Alle elementen die op waardes werken heten \textbf{combinational}, dit betekent dat de output alleen afhankelijk is van de inputs. Elementen die staat bevatten noemen we \textbf{state elements}, simpelweg een register of een stuk geheugen. Een state element heeft tenminste twee inputs en een output. De inputs zijn de data waardes die moeten worden geschreven in het element en de klok, de klok bepaald wanneer de waardes worden geschreven. De output bevat de waarde die eerder de input in kwam.
 
 \textbf{Clocking methodoly} zorgt ervoor dat hardware voorspelbaar is door te bepalen wanneer data valide en stabiel is relatief tot de klok. \textbf{Edge-triggered clocking methodology} zorgt juist dat alle data verandering worden opgeslagen wanneer er een klok "edge" plaats vind, een snelle transitie van laag naar hoog of andersom. Aangezien de state elements alleen een waarde kunnen opslaan moet een \textbf{combinational logic} zowel een state element als input en output hebben. De input is geschreven in een vroegere clock cycle terwijl de output gebruikt kan worden een een volgende clock cycle. Zie figuur 4.2.1
 
\includegraphics[width=\textwidth]{f4_2_1}

Een \textbf{control signal} is een signaal dat gebruikt wordt voor multiplexor selectie of het sturen van de operatie van een functionele eenheid, in tegenstelling tot een \textbf{data signal} wat informatie bevat dat wordt geopereerd door een functionele eenheid. Om een state element te veranderen met een control signal moet er sprake zijn van een \textbf{asserted} signaal. Dit houd in dat er een hooge waarde moet zijn of een waarde die waar is. \textbf{Deasserted} is het tegenovergestelde en betekent dus laag of false.

\subsectionauthor[Max Höfelmann]{Een Datapad Bouwen}
We beginnen aan het bouwen van een datapad door alle groote objecten die nodig zijn om elke klasse uit te voeren in MIPS instructies. \textbf{Datapath elements} zijn elementen die gebruikt worden om op geopereerd te worden of data op op te slaan binnen een processor. In MIPS implementaties bevatten de datapad elementen de instructies, data herinneringen, het register bestand, de ALU en de adders. De PC, program counter, is ook van belang. Dit is een register dat het adres van de huidige instructie. Door de een adder kunnen we de PC verhogen zodat we naar het adres van de volgende instructie gaan. Er zijn ook \textbf{R-format} instructies. Deze lezen allemaal uit twee registers en voeren allemaal een ALU operatie uit op de inhoud van de registers. Onder R-format instructies vallen add, sub, AND, OR en slt.

De 32 general-purpose registers van de processor zijn opgeslagen in een \textbf{register file}. Dit is een collectie van registers waarin elke kan worden geschreven of gelezen, hiervoor is de ALU nodig. 
 
 \includegraphics[width=\textwidth]{f4_3_1}
 
Zoals hierboven in figuur 4.3.1 gezien kan worden zijn er ook meerdere outputs mogelijk.

De MIPS instructies lw en sw maken een 16-bit signed veld in de instructie. Om dit 32-bit te maken is er een \textbf{sign extender} nodig. Deze sign extender vergroot simpelweg de grootte van het gesignde veld door de hoge order bits dupliceren. de bew instructie heeft 3 operanten. De eerste twee zijn twee verschillende registers die worden vergeleken voor gelijkheid. De derde operand is de offset die wordt uitgevoerd als de twee registers gelijk zijn. Er zijn 2 details in de definitie van \textbf{branch} instructies die we in gedachten moeten houden:
\begin{itemize}
\item De instructie set architectuur zegt: de basis van van de berekening van een branch adres, het adres is van de instructie na de branch.
\item De architectuur zet tevens de offset field zo dat hij 2 bits naar links shift, een word offset. Dit zorgt voor een offset field van factor 4.
\end{itemize}
Als de beq true is is er sprake van een \textbf{branch taken}, het branch doel adres wordt de nieuwe CP. Als de beq false is is de branch not taken en vervangt de geincrementeerde PC de oude PC zoals elke andere instructie dit ook doet.

\subsubsection{Een Enkel Datapad Maken}
Het simpelste datapad zal alle instructies willen uitvoeren in een clock cycle. Dit betekent dat geen enkel element twee keer gebruikt mag worden. Elk element dat meerdere keren gebruikt moet worden zal dus gekopieerd moeten worden. Hierdoor zal er een geheugen voor instructies en data moeten zijn. Alhoewel vele elementen gekopieerd zullen moeten worden kunnen er ook vele gedeeld worden verschillende instructie kanalen. We kunnen een multiplexor and control signaal gebruiken om te selecteren welke input gebruikt moet worden bij welke instructie.

\subsectionauthor[Max Höfelmann]{Een Simpel Implementatieschema}
We gaan hier kijken naar de meest simpel mogelijke implementatie van de MIPS subset. Deze implementatie wordt gemaakt met het datapad van de vorige sectie en we voegen daar een paar simpele controle functies aan toe zoals lw, sw, beq, add, sub, AND, OR, set on less than en tenslotte \textbf{jump to instruction (j)}. De 4-bit ALU control input kunnen we genereren door een kleine controle eenheid met als input het functie veld van de intructie en een 2-bit controle veld wat we de \textbf{ALUOp} noemen. De ALUOp bepaald de operatie add (00) voor laden en opslaan, trek af (01) voor beq. De output van de ALU controle eenheid is een 4-bit signaal dat direct de ALU bestuurd door het generen van een van de 4-bit combinaties. Zie figuur 4.4.1

\includegraphics[width=\textwidth / 2]{f4_4_1}

Voor de inputs die niet interessant zijn bestaan \textbf{don't-care termen}. Voor inputs die niet van belang zijn voor de output kan dan een X worden neergezet in de \textbf{truth table}. Zie figuur 4.4.2 hieronder voor een voorbeeld van een truth table.

\includegraphics[width=\textwidth]{f4_4_2}

\subsectionauthor[Max Höfelmann]{De Main Control Unit Designen}
Om te snappen how je de connectie legt tussen velden van instructies naar een datapad is het handig om te kijken naar de formats van de drie intructie klassen: R-type, branch en load-store instructies. Er zijn meerdere belangrijke observaties over deze instructie formats:
\begin{itemize}
\item Het op veld heet de \textbf{opcode} altijd in bits 31:26 en wordt ook wel Op[5:0] genoemd.
\item De twee registers die gelezen moeten worden zijn altijd gespecificeerd door de rs en rt velden op positie 25:21 en 20:16. Dit is zo voor R-type, branch equal en store instructies.
\item Het basis register voor load en store instructies is altijd in bit positie 25:21 (rs).
\item De 16-bit offset voor branch equal en load en store zitten altijd op positie 15:0.
\item Het bestemming register zit altijd in een van twee plekken. Voor load in 20:16 (rt), R-type 15:11 (rd). Dus, we moeten een multiplexor toevoegen om te selecteren in welk vel we de instructie het nieuwe register nummer willen laten schrijven.
\end{itemize}
Met deze informatie kunnen we een instructie label en een extra multiplexor toevoegen aan het simpele datapad.

Waarom wordt Single-cycle implementatie vandaag de dag niet gebruikt? Aangezien de cpi wel 1 is zijn de cycles erg lang en is het gehele proces dus niet efficiënt. Dit zorgt ook voor een conflict met een van de regels uit hoofdstuk 1, \textbf{Make the common case fast}.

De rest van 4.4 is een lang voorbeeld van hoe je dit echt uitvoert, er is zo goed als geen nieuwe informatie.

%-------------------------------------
%              ROBIN
%-------------------------------------

\subsectionauthor[R.A.J. Wacanno]{Het \textbf{Pijplijn}-principe in een notendop}
Het \textbf{pijplijnen} is een veelgebruikte manier om je architectuur instructies te laten uitvoeren.\\ 

\noindent Om te illustreren waarop dit pijplijnen berust kan men een viertal handelingen nemen: A, B, C en D welke na elkander en tezamen herhaaldelijk uitgevoerd moeten worden. Zonder er niet al teveel bij na te denken zou men de vier handelingen steeds na elkaar uit kunnen voeren (als ABCDABCD enz.). Dit is echter geen efficiënte strategie als de combinatie van handelingen vier of vijf keer uitgevoerd moet worden aangezien de tijd die dit zal kosten gelijk zal zijn aan $n \cdot (A + B + C + D)$; ofwel, de som van de tijd die iedere individuele handeling kost maal het aantal keer dat het herhaald moet worden.

Om deze herhaling van stappen in kortere tijd te laten verlopen kun je het principe van pijplijnen toepassen. Als de als voorbeeld genomen proces ABCD op deze manier wordt uitgevoerd zal dit er --- horizontaal afgezet tegen de tijd --- zo uit zien:\\

\begin{tabular}{c c c c c c}
A & B & C & D & &  \\
 & A & B & C & D & \\
 & & A & B & C & D \\
\end{tabular}\\

\noindent En zo zou deze serie handelingen er uitzien als het niet gepijplijnd was:\\

\begin{tabular}{c c c c c c c c c c c c}
A & B & C & D & A & B & C & D & A & B & C & D \\
\end{tabular}\\

\noindent Als men deze twee diagrammen vergelijkt zijn er twee dingen die opvallen: wanneer de gepijplijnde aanpak benut wordt, is de totale uitvoeringsduur drastisch verminderd en bij het gepijplijnd uitvoeren lopen de individuele ABCD-processen parallel aan elkaar. In
dit laatste schuilt dan ook de kracht van het pijplijnen. Door nadat een stap, zoals bijvoorbeeld A, voor de eerst set handelingen is uitgevoerd zal deze onmiddellijk herhaald worden voor de volgende en zo gebeurd dat ook met de andere stappen. Op deze manier wordt op ieder moment toch maar een van de stappen tegelijkertijd uitgevoerd, maar kan toch een significante versnelling gerealiseerd worden door het parallelliseren van de processen.

Onder perfecte omstandigheden zou de versnelling van de uitvoeringstijd van een collectie herhaalde processen als gevolg van pijplijnen gelijk zijn aan het aantal losse stappen waaruit ieder proces bestaat. In dat geval zou de volgende vergelijking kunnen worden opgesteld:

\[
Tijd \ tussen \ instructies_{gepijplijnd} = \frac{Tijd \ tussen \ instructies_{niet \ gepijplijnd}}{Hoeveelheid \ pijplijn\mhyphen stappen}
\]
\hfill\textit{\footnotesize Met instructies worden hierboven processen als die van ABCD bedoeld}\\

\noindent Er is echter vrijwel nooit sprake van perfecte omstandigheden. Het niet evenveel tijd kosten van individuele stappen en het feit dat er aan het begin en einde van iedere uitvoer minder instructies parallel kunnen lopen maakt dat de theoretisch beloofde versnelling niet haalbaar is. Een illustratie hiervan volgt alsmede de toepassing van pijplijnen binnen de MIPS-architectuur.

Zoals stappen A, B, C en D zijn er ook binnen een processor bepaalde handelingen die herhaaldelijk worden uitgevoerd. Dit zijn over het algemeen de volgende vijf stappen:

\begin{enumerate}
\item Het uit het geheugen halen van een instructie. \textit{(Instruction fetch)}
\item Het lezen van registers terwijl de instructie gedecodeerd wordt; hetgeen bij MIPS-instructie van met de reguliere indeling gelijktijdig kan plaatsvinden. \textit{(Register read)}
\item Het uitvoeren van de operatie of berekenen van een geheugenadres. \textit{(ALU operation)}
\item Het benaderen van een operand in het data-geheugen. \textit{(Data access)}
\item Het schrijven van de resultaten in een register. \textit{(Register write)}
\end{enumerate}

\newpage
\noindent Als we nu ter illustratie de \texttt{lw}-instructie nemen heeft deze per stap de volgende hoeveelheid tijd nodig:\\

\begin{tabular}{|l|c|c|c|c|c|c|}
\hline
\textit{\bfseries Instruction} & \textit{\bfseries \shortstack{Instruction\\ fetch}} & \textit{\bfseries \shortstack{Register\\ read}} & \textit{\bfseries \shortstack{ALU\\ operation}} & \textit{\bfseries \shortstack{Data\\ access}} & \textit{\bfseries \shortstack{Register\\ write}} & \textit{\bfseries \shortstack{Total\\ time}}\\
\hline
\textit{Load word} (\texttt{lw}) & 200 ps & 100 ps & 200 ps & 200 ps & 100 ps & 800 ps\\
\hline
\end{tabular}\\

\noindent In de volgende twee figuren zijn zowel de gepijplijnde als de niet gepijplijnde herhaalde uitvoer van \texttt{lw} uitgezet tegen de tijd:\\

\noindent\includegraphics[width=\textwidth]{fig1}

\noindent Door middel van pijplijnen kan de totale uitvoeringstijd van het bovenstaande voorbeeld van 2400 ps naar 1400 ps worden teruggebracht. Hoewel dit natuurlijk een significante verbetering is, is het niet in overeenstemming met de eerdergenoemde aanname dat de reductie in tijd gelijk zou staan aan het aantal individuele stappen.

De discrepantie tussen de theoretische en daadwerkelijke tijd zijn toe te schrijven aan de eerdergenoemde problemen op het gebied van pijplijnen. Allereerst zijn niet alle stappen even lang in duur. Wegens de aard van het pijplijnen is het cruciaal dat er bij het uitvoeren van stappen een bepaalde ritmiek zodat zodat deze steeds op gelijke interval worden uitgevoerd. Indien er dus een stap is die eerder voltooid is dan anderen moet er een korte rust ingevoegd worden om zo de ritmiek te handhaven. Als tweede valt de tijdswinst tegen als gevolg van het geringe aantal herhalingen. Een groter aantal herhalingen zou de verspilling van tijd die plaatsvindt aan het begin en einde van de uitvoer namelijk teniet doen.

Hier is een vergelijking van versnelling tussen --- links --- de 3 reeds beken herhalingen en --- rechts --- een hypothetisch aantal herhalingen van 1.000.000 inclusief de eerdere 3:

\[\frac{2.400\ ps}{1.400\ ps} = 1.71 \qquad \frac{800.002.400\ ps}{200.001.400\ ps} = 4.00\]

\subsubsection{Instructiesets voor Pijplijnen}
In het geval van MIPS, een instructieset expliciet bedoeld voor pijplijnen, zijn op vier fronten keuzes gemaakt die het gebruik voor pijplijnen enorm bevorderen. Allereerst zijn instructies gelijk in lengte. Ten tweede is er een gelimiteerd aantal instructie-indelingen. Ten derde komen geheugen-operanden enkel voor in \textit{load}- en \textit{store}-instructies. Ten vierde speelt ook de uitlijning van operanden in het geheugen hierbij een rol.  

\newpage

\subsubsection{Pijplijnen m.b.t. het Datapad}

Nu het principe van pijplijnen is behandeld is het uiteraard van belang om te bekijken hoe men dit in hardware implementeert. Hieronder is de reeds bekende \textit{single cycle}-architectuur weergegeven met daarin aanpassingen om pijplijnen mogelijk te maken: \\

\noindent\includegraphics[width=\textwidth]{fig2}\\

\noindent Hierin vallen uiteraard de blauwe balken op. Deze representeren kleine stukjes geheugen welke als buffers tussen de verschillende stadia van het pijplijn proces zitten. Waren deze er niet dan zou de uitvoer van ieder onderdeel, zodra deze was verkregen, als invoer naar het volgende component gestuurd worden; met als gevolg dat dit volgende component, daar het nog bezig is met een berekening, plots invoer krijgt welke het nog niet moet behandelen. De buffers zijn aangesloten op de klok en dit zorgt ervoor dat enkel de juiste invoer naar de verschillende componenten wordt gestuurd aan het begin van ieder stadium.

Het is ook goed om op te merken dat de stroom van data binnen de pijplijn altijd van links naar rechts is; met als enige uitzondering op deze regel het \textit{write back}-stadium. Hier is in het bovenstaande diagram ook een stromingslijn zichtbaar vanaf de multiplexer terug naar het register. Omdat de data die tijdens dit stadium wordt teruggeschreven ook een registeradres met zich mee moet krijgen is de lusvormige stromingslijn zichtbaar boven de lijn van terugschrijving. Deze lus loop aan een kan ook door ieder van de buffers en komt zo op het zelfde moment weer terug bij het register als de data die in het register moet worden teruggeschreven.

Een ander belangrijk gegeven is dat de signalen vanuit de aansturingseenheid ook door de buffers gaan, dit is teven gedaan om de stroom door het datapad en de aansturingssignalen welke nodig zijn voor diens verwerking op het zelfde moment bij de betreffende componenten te laten arriveren. Dit alles is in het volgende figuur zichtbaar:\\

\noindent\includegraphics[width=\textwidth]{fig4}\\

\noindent Zoals misschien al was opgemerkt, is het mogelijk dat binnen sommige instructies mogelijk dat het register op twee punten actief is. Normaliter zou dit een probleem vormen aangezien twee verschillende instructie het zelfde component nodig hebben, de snelheid van het register biedt hier uitkomst. Aangezien het aanroepen van het register qua tijdsduur tweemaal sneller is dan het bij een van de andere componenten zou zijn, kan dit component bunnen een cyclus tweemaal worden aangeroepen. In het onderstaande figuur is dit grafisch gedemonstreerd:

\noindent\includegraphics[width=\textwidth]{fig3}\\


\newpage

%-------------------------------------
%               MAX
%-------------------------------------

\subsectionauthor[Max Höfelmann]{Data Hazards: doorgeven vs ophouden}

Hiervoor hebben we voorbeelden gezien die de kracht van pijplijnen laten zien. Nu gaan we kijken naar de problemen, de \textbf{\textit{hazards}}. Zie bijvoorbeeld hier:

\begin{center}
\includegraphics[width=\textwidth]{fig4_7_1}
\end{center}

Alle 4 de instructies zijn afhankelijk van register 2. Als er door meerdere operaties in hetzelfde register wordt geschreven kan de volgende operatie de verkeerde waarde mee krijgen. Dit is op te lossen door bijvoorbeeld \textbf{\textit{Forwarden}}, oftewel doorgeven. Door een \textit{forwarding} unit in het datapad te plaatsen kan de juiste waarde op het juiste moment worden doorgegeven aan elke instructie. We kunnen ook de SUB en AND instructies vervangen met LW en SW instructies om een ophouding te voorkomen. De data bestaat dan namelijk in het MEM/WB register door de LW instructie zodat de SW instructie het kan gebruiken. 

\begin{center}
\includegraphics[width=\textwidth]{4_7_2}
\end{center}

Zoals hierboven te zien is zal bij de \textit{forwarding unit} ook een \textit{multiplexor} toegevoegd moeten worden, in dit geval een 2:1, deze \textit{multiplexor} kiest dan de juiste register input voor de ALU.

Doorgeven werkt niet bij elke hazard die we kunnen ondervinden bij een pijplijn architectuur. Zie de afbeelding hieronder bijvoorbeeld, het register wordt nog gelezen bij \textit{clock cycle} vier maar de ALU moet er wel al operaties mee uitvoeren. Hiervoor zal een ophouding, een \textbf{\textit{stall}}, toegevoegd moeten worden.

\begin{center}
\includegraphics[width=\textwidth]{4_7_3}
\end{center}


\noindent Voor zo'n ophouding toe te voegen kunnen we een instructie gebruiken die geen effect heeft: \textbf{\textit{nop}}. Door twee \textit{nops} tussen elke instructie toe te voegen garandeer je dat er geen \textit{hazard} meer is m.b.t. de registers. 

\subsectionauthor[Max Höfelmann]{Control Hazards}

Elke keer een ophouding plaatsen tot een \textit{branch} compleet is is erg traag. Hierom kunnen we ook voorspellen of een \textit{branch} beschikbaar is. Als de helft van de tijd een \textit{branch} niet ingenomen is, dan kost het erg weinig om een instructie te verwijderen. Deze voorspel optimizatie zorgt er dan voor dat de kostte van de \textit{control hazard} gehalveerd wordt. Om deze instructies te verwijderen worden alle waardes simpel weg naar 0 veranderd, het wordt eigenlijk een \textit{stall}. Het verwijderen van instructies in een pijplijn door een onverwacht geval noemen we een \textbf{\textit{flush}}. We kunnen de snelheid van \textit{branches} ook verbeteren door vooral in het begin van de pijplijn te \textit{flushen} zodat er minder instructies \textit{geflushed} hoeven te worden. Het verwachten dat een \textit{branch} taken is noemen we \textbf{\textit{static branch prediction}}. \textbf{\textit{Dynamic branch prediction}} daarentegen leert van zijn fouten. Als bij de vorige keer de instructie ook al een taken branch had dan onthoud de architectuur dit zodat de volgende keer nieuwe instructies opgenomen kunnen worden om zo de efficiëntie zo hoog mogelijk te krijgen. Om te onthouden of bij de vorige instructie een \textit{branch} taken was of niet bestaat er de \textbf{\textit{branch prediction buffer}}, of \textit{branch} \textit{history} \textit{table}. Hierin staat of een\textit{ branch taken} was in de recente instructies. \textbf{\textit{branch delay slot}} is de plek die direct na een vertraagde \textit{branch} komt. In de MIPS architectuur wordt deze gevuld door een instructie die geen invloed heeft op de \textit{branch}. \textit{Delayed branch} is gelimiteerd in twee opzichten:
\begin{itemize}
\item De restricties van de instructies die in de \textit{delay slots} zitten.
\item Onze capaciteit om te voorspellen tijdens het compileren of een \textit{branch} beschikbaar is of niet.
\end{itemize}
Door deze limitaties is \textit{delayed branch} in populariteit gekelderd. \textit{Dynamic branch} is duurder maar flexibeler en door \textit{Moore's law} snel verdubbelende transistoren wordt het wel steeds goedkoper.

\newpage
\subsectionauthor[Max Höfelmann]{Exceptions}

Een \textbf{\textit{exception}}, ook wel \textbf{\textit{interrupt}}, is een onverwachte actie dat de executie van het programma onderbreekt. Een \textit{interrupt} kan ook van buiten de processor komen. Deze \textit{interrupts} waren orignieel ontworpen om problemen in de processor aan te duiden zoals \textit{overflow}. Er wordt in het boek een speciale terminologie gebruikt voor \textit{exceptions} en \textit{interrupts}, zie tabel.

\begin{center}
\includegraphics[width=\textwidth]{4_9_1}
\end{center}

Voor het operatief systeem om een exceptie te herkennen moet de reden evenals de instructie die het verzorgde duidelijk gemaakt worden. Er zijn twee gebruikelijke methodes om dit te doen. In MIPS is dit door middel van een \textbf{\textit{status register}}. Anders kunnen \textbf{\textit{vectored interrupts}} gebruikt worden. Het adres waarnaar toe de controle wordt gestuurd wordt bepaald door de exceptie bij een \textit{vectored interrupt}. Het operatief systeem kan aan het adres (in hex) zien wat de error is, de adressen zijn gescheiden door 32 bytes of acht instructies. 

Voor pijplijn excepties verloopt het iets anders. Als we de executie niet direct stoppen tijdens de instructie waar de \textit{exception} plaats vind, gaat de oude waarde van het register verloren dat zorgde voor, bijvoorbeeld de \textit{overflow}. Om de \textit{exception} goed te kunnen werpen laten we de instructie door gaan alsof er niets aan de hand is en stoppen we de volgende \textit{cycle} net voordat de instructie begint zodat we waardes uit het betreffende register verkregen kunnen worden. \textbf{\textit{Imprecise interrupt / exception}} vind vaak plaats in pijplijn architecturen door deze niet precieze manier van excepties vinden. De oorzaak kan niet altijd accuraat gevonden worden namelijk. MIPS ondersteund samen met het grootste gedeelte van de huidige computers \textbf{\textit{precise interrupts/ exceptions}}, hier is de precieze oorzaak wel duidelijk.

\subsectionauthor[Max Höfelmann]{Parallelism via Instructions}

Pijplijnen maak gebruikt van het parallel verlopen van instructies. Dit wordt ook wel \textbf{parallelisme op instructie niveau (ILP)} genoemd. Er zijn hierbij twee primaire manieren om de hoeveelheid parallel verlopende instructies te verhogen.
\begin{itemize}
\item We kunnen de diepte van de pijplijn vergroten zodat meer instructies overlappen.
\item \textbf{\textit{Multiple issue}} is ook een optie, de interne componenten worden gekopieerd zodat meerdere instructies in elke pijplijn kunnen plaats vinden. Dus i.p.v. met een wasmachine en droger de was doen, doe je het nu met drie tegelijk! De enige keerzijde hier is dat er ook meer werk nodig is waardes te transporteren tussen pijplijnen omdat er veel meer waardes zijn.
\end{itemize}

Multiple issue heeft twee voorname implementaties, \textit{Static} en \textit{Dynamic}. Bij \textit{static} worden de besluiten door de compiler gemaakt voor de executie. Bij \textit{dynamic} vind dit plaats tijdens de executie door de processor. 

\textbf{\textit{Speculation}} is gebaseerd op het geweldige idee van voorspellen. Speculatie zorgt ervoor dat de processor kan gokken over verschillende eigenschappen van een instructie, hierdoor kunnen andere toepasselijke instructies meteen beginnen. Speculatie kan gedaan worden door middel van de \textit{compiler} of de \textit{hardware}. Helaas voegt ook dit weer een probleem toe aan de lijst, er kunnen excepties plaats gaan vinden op plekken waar er eigenlijk geen sprake van hoort te zijn. Er wordt dan fout gespeculeerd. Deze fouten kunnen vermeden worden door speciale speculatie support. 

\textit{Dynamic Multiple-Issue} processoren zijn ook wel bekend als \textbf{\textit{superscalar}} processoren. Bij deze processoren wordt besloten of er een, nul, or meerder instructies tegelijk uitgevoerd moeten worden. Om de efficiëntie zo hoog mogelijk te houden maken deze processoren gebruik van \textbf{\textit{dynamic pipeline scheduling}}. Dit is \textit{hardware} support voor het herordenen van de instructie executie om zo doende \textit{stalls} te kunnen voorkomen. Hieronder zie je de werking van \textit{Dynamic pipeline scheduling}.

\begin{center}
\includegraphics[width=\textwidth]{4_10_1}
\end{center}

De \textbf{\textit{commit unit}} is waar er besloten wordt of het veilig is om het resultaat door te laten gaan. De \textbf{\textit{reservation station}}s zijn buffers waarin een functionele unit zit die de operanten en operatie vast houd. Deze unit wordt vaak de \textbf{\textit{reorder buffer}} genoemd. Aangezien de instructies bij een \textit{dynamic pipeline schedule} op een andere volgorde uitgevoerd kunnen worden wordt het ook wel een \textbf{\textit{out-of-order execution}} genoemd. Als ze wel op volgorde worden weergegeven aan de programmeur is er spraken van \textit{in-order} \textit{commit}. Hedendaags gebruikt elke \textit{dynamic pipeline schedule} de \textit{in-order commit}.

Je vraagt je misschien af waarom \textit{superscalar} processors gebruikt maken van \textit{dynamic scheduling}. Er zijn die redenen:
\begin{itemize}
\item Niet elke stall is voorspelbaar.
\item Als hij speculeerd is de exacte volgorde van instructies niet duidelijk tijdens het compileren.
\item Doordat de pijplijn de hele tijd van \textit{latency} en grootte veranderd is de meest efficiënte manier van compileren steeds anders, hierdoor is het uiteindelijk minder efficiënt.
\end{itemize}
\textit{Dynamic scheduling} zorgt ervoor dat de \textit{hardware} de meeste van deze problemen kan verbergen.

\subsectionauthor[Max Höfelmann]{Real Stuff: The ARM Cortex-A8 and Intel Core i7 Pipelines}

\begin{center}
\includegraphics[width=\textwidth]{4_11_1}
\end{center}

Zie hierboven de specificaties van beide processoren.

Deze subsectie gaat voornamelijk over hoe beide processoren zich gedragen. Advies is om dit door te lezen in het boek zodat de stof duidelijker wordt. Hieronder een aantal begrippen die gebruikt worden in deze subsectie:
\begin{itemize}
\item \textbf{\textit{Microarchitecture}}: de organizatie van de processor, waaronder de grootte functionele \textit{units}, hen connecties en controle.
\item \textbf{\textit{Architectural registers}}: De instructieset van de zichtbare registers van de processor. Bijv. de 32 int en 16 \textit{float point} registers in MIPS.
\end{itemize}