AOS - 02 - HARDWARE INSIGHTS II

La famiglia di architettura x86 è stata introdotta con il chipset Intel 8086 , sviluppato tra il 1976 e il 1978. L'intel 8086 aveva 14 registri (AX, BX, ...), e al posto di utilizzare una pipeline processava le istruzioni tramite un ciclo a quattro fasi

\[ [\text{FETCH}, \text{ DECODE}, \text{ EXECUTE}, \text{ RETIRE}] \]

L'istruzione \(\text{RETIRE}\) in particolare veniva utilizzata per effettuare il commit the instruction, ovvero per rendere visibili tutti i side effects causati dell'istruzioni all'insieme delle risorse esposte all'ISA.

Nel 1989 è stato poi introdotto il nuovo processore, l'intel 80486, detto anche i486 . Questa volta era presente una pipeline a \(5\) stages.

Notiamo che i due stages di decode derivano dal fatto che l'x86 ha un sistema molto complesso di indirizzamento della memoria.

Successivamente all'introduzione di questa pipeline i programmatori hanno notato come la pipeline introdotta nel i486 non era molto performante quando c'era una forte dipendenza dei dati nel program flow. Un noto esempio di forte dipendenza dei dati capita quando vogliamo scambiare il valore di due registri. Infatti, se non si vuole utilizzare un terzo registro (e nella programmazione di sistema tutti i registri sono fondamentali, quindi è cosa buona e giusta risparmiare un registro), e se non si vuole avere un accesso alla memoria (che renderebbe il program flow memory-bound, e conseguentemente più lento), l'unico modo per ottenere questo swap è utilizzando la seguente sequenza di operazioni

\[ \text{XOR}(a,b), \text{XOR}(b,a), \text{XOR}(a,b) \]

Con il Pentium Pro la intel introduce il concetto di superscalarità di una pipeline. Una pipeline superscalare è una pipeline in cui è possibile eseguire più istruzioni che fanno la stessa operazione in modo parallelo utilizzando risorse hardware duplicate. L'idea alla base di una pipeline superscalare è quella di eseguire gli stages di Execute (EX) di più istruzioni in modo parallelo, andando ad introdurre una ridondanza a livello hardware.

Con questo modello di pipeline si introduce il concetto di OOO Execution, e quindi l'ordine in cui le istruzioni vengono esegutie a livello hardware nella pipeline non rispetta più l'ordine in cui le istruzioni appaiono nel program flow. In un modello OOO una istruzione va avanti finché le risorse hardware e i dati di cui l'istruzione ha bisogno sono disponibili.

L'architettura hardware della pipeline che permetteva la OOO execution utilizzata nel Pentium Pro era basata su un algoritmo trovato da Robert Tomasulo e già implementatoo dalla macchina IBM 360/91 nel 1966. Nell'implementazione dell'IBM il concetto di OOO execution era perà limitato solo ad una determinata classe di istruzioni, mentre nell'implementazione della intel tutte le istruzioni possono potenzialmente essere eseguite OOO.

Anche se l'esecuzione delle istruzioni non avviene in ordine, il commit finale (\(\text{RETIRE}\)) delle istruzioni deve comunque avvenire nell'ordine definito dal programma. Dunque, volendo sintentizzare, la out-of-order execution si basa sui due seguenti principi:

1. Il commit delle istruzioni viene effettuato rispettando l'ordine delle istruzioni come definito dal program flow.

2. Le istruzioni indipendenti (sia nei dati che nelle risorse), vengono processate il prima possibile.

In uno scenario OoOE dobbiamo essere in grado di preservare le eccezioni che possono essere sollevate durante l'esecuzione del program flow.

Il fatto che durante la OoOE vengono generate delle eccezioni non implica automaticamente che queste eccezioni appartengono effettivamente al program flow che si sta eseguendo, in quanto l'istruzione che ha generato l'eccezione, diciamo l'istruzione \(A\), potrebbe aver sorpassato un'altra istruzione, diciamo l'istruzione \(B\), che nel program flow la precedeva, e che a sua volta, se eseguita, avrebbe generato una eccezione. Ma allora tutte le istruzioni che seguivano \(B\) non dovevano essere presenti nel program flow, e quindi il program flow non avrebbe dovuto generare l'eccezione derivante dall'esecuzione dell'istruzione \(A\). Queste eccezioni che non appartengono al program flow ma che vengono generate per via della OoOE prendono il nome di phantom execptions.

Il fatto che l'istruzione \(A\) è stata eseguita in modo speculativo prima dell'istruzione \(B\), anche se non ha effetti sulle risorse hardware esposte dall'ISA, implica comunque degli effetti micro-architetturali per il sistema. Recentemente si è scoperto che osservare in modo indiretto questi effetti micro-architetturali può permette di inferire informazioni confidenziali sul sistema. Le vulnerabilità più famose di questa categoria prendono il nome di Spectre e Meltdown, e verranno attentamente studiate nel proseguire del corso.

Supponiamo di avere due istruzioni \(A\) e \(B\) in ordine \(A \to B\). Andiamo a vedere i possibili conflitti tra le due istruzioni

• RAW (Read After Write): Se nel program flow l'istruzione \(A\) scrive su una locazione di memoria su cui poi legge l'istruzione \(B\), andando ad invertire \(A\) e \(B\) l'istruzione \(B\) leggerà un valore "stale".

• WAW (Write After Write): Se nel program flow l'istruzione \(A\) scrive su una locazione di memoria e su cui poi ci scrive \(B\), andando ad invertire l'ordine tra \(A\) e \(B\) ottengo che il risultato finale nella memoria è quello scritto da \(A\), e non quello scritto da \(B\), come dovrebbe essere.

• WAR (Write After Read): Se nel program flow \(A\) legge da una locazione di memoria su cui poi ci scrive \(B\), andando ad invertire l'ordine tra \(A\) e \(B\) ottengo che \(A\) legge un valore nel futuro della sua esecuzione, che non avrebbe dovuto leggere.

Alla base dell'algoritmo di Tomasulo ci sono le seguenti idee algoritmiche:

• Per gestire il conflitto di tipo RAW tengo traccia di quando i dati richiesti in input dalle istruzioni sono pronti, e appena sono pronti propago le informazioni a tutte le istruzioni che necessitano di questi dati.

• Per gestire i conflitti WAR e WAW utilizzo il concetto del register renaming.

Quando una istruzione viene processata dalla pipeline, l'hardware cambia il suo stato interno al fine di processare l'istruzione. Lo stato dell'architettura esposto all'ISA invece cambia solamente dopo aver effettuato l'operazione di RETIRE. Questo vuol dire che tutti i cambiamenti dell'hardware necessari per eseguire una determinata istruzione ma che avvengono prima del RETIRE non sono visibili dalle risorse offerte dall'ISA (registri, memoria e operazioni per interfacciarsi con registri e memoria). Si parla quindi di micro-architettura di sistema per intendere tutte le risorse hardware, anche quelle non esposte all'ISA, che servono per eseguire le istruzioni che compongono i vari program flow che vogliamo eseguire.

L'istruzione CPUID viene utilizata per ottenere l'identificativo numerico del processore su cui stiamo lavorando. Questa istruzione però, come side effect, va a svuotare la pipepline (flush of the pipeline).

Nella programamzione di sistema moderna è possibile ottenere tale informazione senza l'utilizzo di questa istruzione.