The Dark Side of Hardware Upgrade Forum

Per capire come funziona un processore bisogna definire innanzitutto il concetto di "ambiente" o "thread".
Lo "stato" di un processo è sempre rappresentabile come l'insieme della sua immagine di memoria più lo stato dei suoi registri.
Ecco, "Ite, missa est!"... quella frase nella sua "durezza" spiega esattamente l'importanza dei registri.

Facciamo un passo indietro... cos'è un registro ?
Un registro è uno "spazio" in cui vengono tenuti dei dati; un processore ha un certo numero di registri (da quattro dei processori "a stack" fino alle centinaia degli obsoleti SPARC passando per i sedici dei 680x0, i sessantaquattro dei PPC ed i quattordici -contando anche quelli di segmento/selettore- degli x86 "classici" ) e "lavora" solo su quelli.

I registri sono "i posti dove le cose succedono" o, per meglio dire, sono gli unici "sorgenti" e le uniche "destinazioni" che la CPU può usare per compiere le operazioni: se una CPU deve fare una somma fra due valori i due valori devono essere in due registri, ed il risultato sarà messo in un registro.
Spesso e volentieri l'ISA (il set d'istruzioni) è fatto per nascondere questa piccola cosina ma nella pratica (che poi è anche logico) perché la CPU "usi" un valore deve "averlo" al suo interno.

Essenzialmente si distingue fra registri visibili e registri nascosti, i registri visibili sono quelli che si possono accedere dall'ISA del processore stesso mentre quelli nascosti (che sono tanti e praticamente non documentati da nessuna parte) sono quelli che contengono valori intermedi, temporanei e similia.
Solo i registri visibili sono necessari per descrivere il funzionamento della macchina (e solo quelli vengono "salvati" se si vuole "salvare" lo stato di un processo) ma tutti sono necessari perché una CPU funzioni correttamente.

Ok questa parte è stata abbastanza difficile a dirsi ma purtroppo i registri sono praticamente il cuore della CPU ed un po' di difficoltà ORA può significare molti meno problemi ed incomprensioni in seguito.

Facciamo un classico esempio : mov ax,24h
Quest'istruzione x86 mette nel registro (visibile) AX il valore 24 (h stà per esadecimale, quindi parliamo del "nostro" 36), quest'istruzione per essere eseguita coinvolge non meno di una decina di registri...
...c'è l'IP (instruction pointer) che contiene l'indirizzo a quest'istruzione e che viene incrementato dopo che quest'istruzione è stata eseguita, c'è qualche forma di MAR (memory address register) che contiene l'indirizzo EFFETTIVO in memoria di quest'istruzione, c'è qualche forma di MDR (memory data register) che conterrà l'istruzione stessa una volta recuperata dalla memoria, c'è qualche registro temporaneo su cui verrà "scaricato" il valore 24h, c'è il registro AX che verrà sicuramente coinvolto, ci sono tutti i registri di translazione dell'indirizzo (che su x86 e non solo sono tanti ma spesso sono pure male assortiti) e c'è qualche forma del registro (in parte visibile) dei flag.
Si, 'sta squadra di registri per mettere un fottutissimo 36 in una celletta dentro un processore...
...non vi preoccupate, nessuno (tranne forse all'Intel/AMD) studia in dettaglio tutto il procedimento anche perché mettendoci dentro anche le paranoie dovute a pipeline, stages, threading e compagnia cantante c'è abbastanza roba per mandare al manicomio un bel po'di gente... però se volete sapere COME funziona un processore è giusto che sappiate che:
1. tutto passa, prima o poi, dai registri
2. i registri sono uno componenti fondamentali nei processori

Il resto verrà da sé (e da me, se ho il tempo di continuare)

La CPU opera sui registri "a tempo zero", ovvero senza dover introdurre dei wait state per attendere che i dati su cui opera vengano recuperati.
Questo rende decisamente pratico lavorare sui registri, e tuttavia i registri rappresentano solo un "punto di passaggio" per i dati in quanto una CPU ne ha un numero estremamente ridotto.
La massima parte dei dati viene quindi "caricata" sui registri dalla memoria, elaborata NEI registri e quindi riscritta in memoria.
Il problema è che la RAM, nonostante tanti passi avanti, rimane lenta rispetto alle CPU.

La RAM di per sé stessa è fatta usando le stesse tecnologie produttive dei processori per cui teoricamente non dovrebbe essere un problema fare RAM veloci quanto le CPU... nella pratica invece bisogna accontentarsi di molto meno.
Il problema è legato innanzitutto ad un necessario compromesso: meglio poca RAM velocissima o tanta RAM più lenta ?

La RAM velocissima è "facile" a farsi, basta usare quattro porte logiche per ogni bit (un flip-flop), ovvero un bel circuitino noto come SRAM.
Il problema qui è una porta logica richiede quattro transistor:

...per cui mantenere un bit in totale occorrono 16 (4x4) transistor.

La RAM meno veloce, ovvero la DRAM, è ancor più facile... basta usare l'effetto capacitivo di un transistor.
Le DRAM (dette anche "la RAM come la conosciamo oggi") hanno una densità altissima... essenzialmente perché nello spazio di un bit di SRAM ci stanno tranquillamente sedici bit DRAM.
Dov'è la fregatura ?
A dire il vero sono due...
[*] La prima è che "nessuno è perfetto" si applica anche ai transistor per cui per quanto bene siano fatti le cariche "immagazzinate" per effetto capacitivo tendono comunque a "perdersi"... da qui la necessità, ogni tot di tempo, di "leggere" il transistor e riscriverlo per "rinnovare" la carica (quello che comunemente viene detto refresh), e serve un circuito che svolga questo compito.
[*] La seconda è che un bit di SRAM lo puoi leggere mille volte senza particolari problemi... un bit di DRAM quando lo leggi lo "cancelli" e per scriverlo devi prima cancellarlo per cui le operazioni di lettura e scrittura sono molto più complesse (e lente).

Ovviamente viste queste premesse quel che salta all'occhio è che per gli usi in cui è necessaria immediatezza, velocità ed un numero ristretto di celle di memoria (i registri, ma anche le cache) la SRAM è una scelta quasi obbligata mentre quando c'è da immagazzinare una buona mole di dati le DRAM risultano più adatte (anche perché serve UN circuito di refresh ed UN circuito di lettura/scrittura per ogni chip... per cui "scalano" bene).

Un altra considerazione, tutt'altro che secondaria, è che la CPU comunica con la RAM (direttamente o attraverso dei chip di collegamento, vedasi northbridge) attraverso delle piste su una scheda madre.
In sé questo non sarebbe un problema se non fosse che queste piste sono in genere lunghissime (per i "canoni" di un circuito integrato) ed elettricamente poco bilanciate (fra socket, slot e via dicendo).
Và da se che i segnali su queste piste possono far viaggare i segnali a velocità limitate (se confrontate alle velocità all'interno dei chip).
Metteteci anche che il numero di piste è limitato (come il numero di pin su un socket) ed avete idea del secondo grosso collo di bottiglia.

Ricapitolando l'accesso alla RAM è una grossa gatta da pelare.
I "canali" che collegano la CPU alla RAM sono piccoli (tipicamente la SDRAM/DDR/DDRn ha bus a 64bit) e lenti (a causa dei problemi elettrici).
Segue quasi automaticamente che l'accesso alla memoria ha anche una latenza elevata, cioè che da quando si fa richiesta a quando i dati cominciano ad arrivare passa un bel po'di tempo... tempo in cui la CPU è ferma e perde cicli.
Per limitare il problema s'è innanzitutto cambiata l'essenza delle RAM... le RAM oggi non sono più dei banchi di memoria a cui la CPU accede direttamente (stile 386) ma a loro volta dei processori con "dentro" milioni di celle di memoria dinamica che ricevono comandi dalla CPU, tipicamente "leggi"(mi) o "scrivi"(mi).
L'aumento della complessità dei banchi è minima, specie considerando che oramai banchi da 1GBit sono comuni, ed in cambio di ciò s'è potuto fare moltissimo.
Oggi i banchi di memoria sono "programmati" all'avvio, quando la CPU imposta i timing dei vari segnali migliorando il più possibile i tempi di risposta, abbassando il lag ed usando diversi trucchi per migliorare la "resa" delle memorie in generale.

E tuttavia la latenza resta; in un sistema che và a pipeline qualsiasi ritardo nell'accesso ai dati è un dramma per le performance complessive dei sistemi... e se un processore idealmente dovrebbe eseguire un istruzione per ciclo di clock bisogna fare in modo che il processore possa LEGGERE un istruzione per ciclo di clock.

Per questa ragione si sono ideate le cache.
Il concetto di cache è abbastanza facile, in pratica si tratta di avere memorie più piccole e veloci in cui mettere i dati usati più spesso... visto che le istruzioni sono eseguite in sequenza e vista la regola dell'80-20 (l'80% del tempo d'esecuzione di un programma è speso nel 20% del codice) poter mettere quella parte del codice (e magari i dati più usati) in memorie a scarsissima latenza ed alta velocità permetterebbe di accelerare tremendamente l'esecuzione dell'intero programma.

Ora andiamo nel dettaglio... come funzionano le cache ?
Beh, in teoria appena la CPU fa richiesta di un accesso ad un area di memoria quell'area (se non già presente) viene "caricata" nella cache dalla RAM cosicché gli accessi successivi (si suppone che ci sia una certa "località", che cioè i prossimi accessi saranno "nei dintorni" del dato richiesto) saranno fatti da/verso la cache, lasciando indisturbata la RAM.
Ma, prima d'andare avanti, diamo un occhiata a dei dati "real world"... guardiamo quanto sono veloci le cache:



Qui le cache sono di tre "livelli", ovvero c'è una gerarchia di cache per cui più si "sale" di livello (informaticamente "più in alto" vuol dire "numero più basso") più le cache diventano piccole e veloci.

Le cache L1 sono sempre (dai tempi del 486 e simili) interne ai singoli core delle CPU e sono fatte di SRAM con lo stesso processo produttivo e la stessa velocità della CPU (sono, "fisicamente", un pezzo dei singoli core).

Le cache L2 sono più lente ed a seconda dell'architettura possono essere interne o esterne alla CPU vera e propria (ad esempio i primi PentiumII avevano cache L2 "esterne" alla CPU) e, a seconda dell'architettura, possono essere "dedicate" ad un singolo core (come avviene ad esempio per i Phenom) o "comuni" a tutte le CPU (come avviene ad esempio nei Core2Duo/Quad). La L2 è tipicamente SRAM anche se, a seconda dell'architettura, può essere "clockata" a velocità più bassa rispetto a quella della CPU (i famigerati Celeron Mendocino o lo stesso Xenon della XBox 360 hanno L2 a velocità dimezzata rispetto alla CPU) per limitare i consumi ed il calore prodotto.

La cache L3 è un "optional", nel senso che nelle CPU consumer è spuntata da tuttosommato pochissimo tempo e rappresenta la cache più lenta (ma anche la più grossa) del gruppo. Spesso "viaggia" a velocità più basse (per le stesse ragioni per cui si abbassa la velocità della cache L2) ed a volte è fatta con DRAM "veloci" (per poter offrire, in cambio di una velocità minore una maggior "densità" di bit per superficie... lo fa, ad esempio, IBM sulle sue CPU) ed a seconda delle architetture può essere su un chip a parte.
La L3 è quasi sempre comune a tutti i core di una stessa CPU.

Una particolarità delle cache L1 è che (tranne che sui defunti Alpha) sono fatte secondo l'"harvard architecture" ovvero sono DUE cache separate, una per le istruzioni ed una per i dati... e questo perché istruzioni e dati vanno gestiti in modo diverso ed hanno alcune peculiarità che ne rendono più semplice la gestione "divisa" (ad esempio la CPU non scriverà mai sulla cache istruzioni).
In alcuni processori (ad esempio i Pentium4) la cache istruzioni L1 non contiene le istruzioni in quanto tali ma la loro forma già decodificata (ed infatti la dimensione della cache L1 sui Pentium4 è data in uOps e non in bytes).

Oltre alle cache L1 istruzioni e dati ci sono altre cache "specifiche" messe per usi particolarissimi (le cache TLB) che servono in campi particolari e che vedremo altrove, quando si parlerà della gestione della memoria.

Giusto per nota eccovi la foto della litografia di un Phenom a 65nm (core Agena):



Notate la cache L3 condivisa messa fisicamente "da parte" (perché, potendo essere più lenta, si può anche "spostare" in una zona più "periferica" del chip), le cache L2 (una per core) fisicamente adiacenti ai rispettivi core e le cache L1 che... non si vedono perché sono fisicamente "dentro" i core stessi (ma sono comunque riconoscibili).

E qui si può vedere come "appare" la CPU al normale CPUID:



Da notare come le cache L1 appaiano come due cose distinte, quella istruzioni e quella dati.


Notate anche che le cache (che in questo caso sembrano essere tutte SRAM) "riunite" occupano circa il 33% della superficie totale del chip pur essendo, nell'insieme, poco più di 4.5 MB.

(se v'interessa che continui fatemelo sapere, altrimenti risparmio tempo )

Piccolo appuntino... la cache funziona a blocchi e non a byte.
Per semplicità d'ora in poi noi parleremo di "cella" riferendoci ad un "blocco" (in inglese si parla di "line size"), ovvero un certo numero di locazioni di memoria consecutive (ad esempio 64 byte); e quando parleremo dell'indirizzo della cella ci riferiremo all'indirizzo della prima locazione del blocco.

Per nota diciamo anche che quando, alla ricerca di una cella, la si trova in cache si parla di "cache hit" mentre quando non la si trova siamo in presenza di un "cache miss".

A differenza della memoria le "righe" della cache contengono, oltre al dato, sia l'indirizzo "reale" a cui corrisponde la cella "cacheata" (o parte di esso) sia delle flag che, a seconda del tipo di cache, indicano se la cella è attualmente usata, se è stata modificata rispetto alla "versione" sulla RAM, quand'è stata usata l'ultima volta e via dicendo.
In genere l'ultimo accesso fatto alla cella serve per capire quali celle "scaricare" quando occorre uno "spazio" libero mediante l'algoritmo di eliminazione dell'"usato meno di recente" (o LRU).

Ora... le cache si dividono anche a seconda del "metodo" con cui immagazzinano i dati.
Questi due modi dipendono essenzialmente dal sistema con cui viene fatta la ricerca per vedere se una particolare locazione di memoria è in cache o no.
Stiamo parlando delle cache "associative" e di quelle "direct mapped".

In una memoria direct mapped una locazione di memoria è "cacheabile" (aka la puoi mettere) solo in una locazione della cache.
In pratica basta fare l'indirizzo di memoria modulo la dimensione della cache e si ha un indirizzo "di cache".
Se in quella cella di cache c'è l'indirizzo che interessa a noi bene, altrimenti è un cache miss.
Il vantaggio della cache direct mapped è che è una cosa semplicissima risalire alla posizione della cella partendo dall'indirizzo, basta fare un modulo (che, per le potenze di due, significa semplicemente troncar via i bit più alti), lo svantaggio è che questo sistema è poco flessibile, e può provocare, in casi particolari, situazioni veramente brutte a vedersi (col caso limite di quando si devono spostare dati fra due celle aventi lo stesso "modulo").

L'altro estremo sono le memorie "associative" in cui, semplicemente, l'indirizzo richiesto viene confrontato con l'indirizzo contenuto nelle celle e se c'è la corrispondenza abbiamo un cache hit, altrimenti la locazione che cerchiamo è solo nella RAM.
Niente paura, il "confronto" può essere fatto in parallelo su TUTTE le celle contemporaneamente e con le memorie associative una cella può stare in qualsiasi locazione della cache senza problemi.
Dove le memorie associative invece perdono è nella complessità... perché inserire un comparatore per ogni indirizzo di cella significa usare tante porte logiche il che vuol dire tanti transisor e quindi, ovviamente, tanto spazio sul chip.

Ma visto che una soluzione è troppo drastica e l'altra è troppo costosa spesso si ricorre ad una via di mezzo le "x-way associative" che sono un mix fra le due tipologie.
In pratica nelle memorie associative a X vie una determinata cella può essere solo su X (con X una potenza di 2, tipicamente 4,8 o 16) celle della cache.

Ecco un immagine che mostra la differenza fra una cache direct access ed una 2-way associative:


E qui c'è un grafico che mostra le percentuali di hit e miss tipiche a seconda della tipologia delle cache:

Come si può vedere mentre la cache "direct access" tende a provocare un bel po'di miss già una 2-way associative è decisamente più "performante".

Ed ecco alcuni dati "reali" relativi all'Intel i7 950:


...e quelli dei PhenomII X4:


Qui il "line size" è la dimensione della cella (intesa come blocco d'indirizzi consecutivi) in byte.

Complinenti

Una piccola nota (più che altro di carattere informativo) su come vengono gestite le SCRITTURE sulla cache.

Partiamo dal principio, perché il problema di base è quello della coerenza (che ha altri risvolti che vedremo in seguito).
Per far funzionare "meglio" la CPU noi copiamo su una memoria veloce il contenuto di piccole parti della RAM, questo è essenzialmente il concetto di cache... ma chi c'assicura che la RAM e la cache contengano sempre contemporaneamente gli stessi dati ?
Semplifichiamo il concetto... immaginiamo che a cambiare i contenuti di una cella possa essere la sola CPU... quando la CPU modifica una cella sulla cache il contenuto della cache ovviamente non corrisponde più al contenuto sulla memoria (e, in certi casi, sulle cache di livello inferiore).

Ci sono due modi per "gestire" la cosa, il primo è "espandere" il comando di scrittura a tutte le cache di livello inferiore ed alla RAM, in questo modo la scrittura passa attraverso (write through) la cache.
Con questo sistema non esiste un vero e proprio problema di sincronia, semplicemente perché la scrittura avviene tanto nella cache quanto in RAM, l'unico problema è che se anche la scrittura in RAM è asincrona (cioè "indipendente" dalla CPU vera e propria) i tempi sono quelli... và da sé che se per scrivere il dato in RAM ci vogliono (esempio) 140 cicli di clock e prima che passino quei 140 cicli c'è un altra scrittura questa "ferma tutto" fino quando la prima non termina.

Il secondo invece è quello di limitare le scritture alla cache di livello più alto, indicando in un flag che la cella è stata sporcata dalla CPU (dirty).
Quando la cella verrà espulsa dalla cache (secondo l'algoritmo LRU) se è "dirty" l'intera cella verrà riscritta in RAM (o nella cache inferiore), in pratica si effettuerà la scrittura solo al "ritorno" della cella (write-back).
In write-back esiste effettivamente un problema di "coerenza", perché è ammissibile che la "copia" cache della cella sia "più aggiornata" di quella in memoria... per questo esistono meccanismi addizionali che permettono di risincronizzare le cache.

Oggi nelle CPU si usa quasi esclusivamente il sistema write-back semplicemente perché s'è visto che è più efficiente con le CPU odierne.

Uno dei problemi con le write-back è che a volte un dispositivo "terzo" che ha accesso alla memoria (come un controller SATA, un altro core o un altra CPU) ha bisogno di accere alle "ultime versioni" di una cella in cache... e la cosa diventa abbastanza complicata.

Nel caso più semplice facciamo l'esempio di un dispositivo che comunica con il resto del computer attraverso un area di memoria condivisa (come ad esempio le schede video).
Una particolare area (che viene "comunicata" al resto del computer all'avvio) viene quindi "riservata" a quel determinato dispositivo ed ogni lettura/scrittura in quell'area corrisponderà ad una lettura/scrittura su registri/aree di memoria "condivise" dal dispositivo stesso.
Questo sistema d'interfacciamento prende il nome di MMIO o "memory mapped I/O" (input/output mappato in memoria).
Ovviamente se quell'area di memoria è, in effetti, "gestita" da un dispositivo vuol dire che, indipendentemente dalla tipologia di cache che utilizziamo, ci sarà un problema di coerenza.

In questi specifici casi la soluzione è una ed abbastanza netta: non usare le cache in quelle aree di memoria.

Nella pratica questo approccio è poco pratico perché effettuare una lettura "esplicita" che passi per la RAM per ogni dato è un grosso limite, per questo in genere i dispositivi (a partire da quelli PCI) tendono a distinguere fra aree "prefetchable" e "non-prefetchable".

Ecco un "estratto" da un "lspci -v -v -s 00:02.0" (aka i dettagli della VGA integrata della mia macchina linux):


Si noti che s'è mantenuta "prefetchable" l'area più grande, quella che corrisponde alla memoria video in sé mentre l'area dei registri mappati in memoria è "non-prefetchable".
Questo non significa che l'area "prefetchable" non possa avere problemi di coerenza, significa che la CPU accede ed effettua il caching dell'area... stà poi al programma (=driver) occuparsi di eventuali problemi di coerenza.
Di contro l'area "non-prefetchable" è un area che può dare seri problemi per come la CPU potrebbe accedere ai dati, o perché è necessario un certo modo d'accedere alla memoria, per questa ragione s'è indicato esplicitamente che gli accessi all'area devono essere tutti diretti.

Un caso, ad esempio, è quando ci sono (specie su vecchi dispositivi) registri multiplexati o "ripiegati".
Ad esempio nelle vecchie VGA (parlo di porte, ma il ragionamento è lo stesso) molti registri anticamente erano accessibili attraverso solo due locazioni.
In una mettevi l'"indirizzo interno" del registro, nell'altra leggevi/scrivevi il dato (multiplexing).
In altre aree invece un dato "lungo" (16-32 bit) andava inserito un byte alla volta mediante scritture successive.

Ora queste oscenità sono sparite del tutto o quasi ma il punto resta : in diversi casi è preferibile che una lettura o una scrittura corrispondano ESATTAMENTE una scrittura o una lettura sul bus esterno.

Dai, metti anche 2 parole sullo snooping e i meccanismi di cache coherence, in presenza di piu' core o anche solo con DMA o altre periferiche ad accesso diretto della ram come le schede grafiche sui PCI express.
Magari inseriscilo piu' sopra, cosi' tiene il filo del discorso.

Non ho voglia di fare una specie di lectio magistralis, anche perché non ne ho i titoli. Tutti possono intervenire.
Anyway già che ci siamo andiamo un po'avanti.

Un altro modo per "forzare" la coerenza è quello di chiedere esplicitamente (attraverso un apposita istruzione dell'ISA) lo svuotamento delle cache.
Queste istruzioni, presenti un po'in tutte le architetture (su x86 l'istruzione si chiama WBINVD) sono in genere privilegiate (cioè possono essere eseguite solo dai driver e da alcune parti del sistema operativo, altrimenti la CPU "da errore" o ignora il comando) e servono per "preparare" il sistema a qualche evento (come un trasferimento DMA) su architetture prive di sistemi di controllo più flessibili.
Lo svuotamento "forzato" delle cache viene detto "cache flush" ed è un evento "traumatico" in quanto ferma il processore per moltissimo tempo (e, quel che è peggio, più cache si ha a disposizione più cicli occorrono per completare lo svuotamento).

Un cache flush, a seconda dell'architettura, può anche essere richiesto "esternamente" (cioè, un dispositivo può inviare alla CPU un segnale che forza il cache flush) ad esempio da un controller.

Per evitare situazioni così "tragiche" sono stati escogitati specifici sistemi (interni ed esterni alla CPU) che chiedono flush selettivi di alcune parti della memoria o che arrivano a mantenere la coerenza delle cache forzando flush parziali delle celle interessate e/o invalidando solo alcune specifiche parti (ad esempio se un controller disco deve scrivere tutte le celle da A a B si può mandare via BUS un messaggio al controller cache dicendo che tutte le celle da A a B non sono più valide, analogamente per la lettura si può richiedere un flush "limitato" all'intervallo fra A e B).
C'è un universo che orbita intorno alla coerenza, e molte cose hanno a che fare con la specifica struttura della CPU e del chipset.
Noi qui ci limitiamo a presentare un altro interessante argomento.
I computer oggi hanno diversi core con diverse cache, e spesso hanno addirittura diverse CPU... come si mantiene la coerenza fra cache e sistemi ?

Capiamoci meglio... se una CPU dual core ha nella sua cache "privata" (es L1) una cella e questa cella venisse "richiesta" dall'altro core ? E se l'altro core dovesse scrivere in quella cella ?
Benvenuti nel fantastico mondo di MESI e dei suoi discendenti.

M.E.S.I. ovvero Modified, Exclusive, Shared, Invalid (noto anche come "Illinois protocol") è essenzialmente il più diffuso sistema per mantenere la coerenza fra diverse cache.
I quattro stati che formano l'acronimo indicano altrettanti stati in cui può trovarsi una cella di cache:
M - Modified - La cella è presente solo in questa cache, ed è "dirty" (ovvero diversa dalla "versione" in RAM)
E - Exclusive - La cella è presente solo in questa cache, ed è "clean" (ovvero identica alla "versione" in RAM)
S - Shared - La cella è presente in questa e possibilmente in altre cache, ed è "clean"
I - Invalid - La cella non è valida
Le politiche che legano il passaggio da uno stato all'altro e le azioni che ne derivano permettono di gestire in maniera abbastanza efficiente la cache ed assicurare la coerenza fra di esse.

Lungi dall'essere perfetto (non per nulla ci sono diversi "discendenti" che aggiungono ulteriori "stati" oltre ai quattro sopra elencati) MESI è un buon metodo per mantenere la coerenza fra diverse cache e la memoria ed è sostanzialmente lo standard "de facto" per le cache write-back.

Il protocollo in sé non è altro che un sistema che ascolta eventuali letture e scritture su un bus comune e si occupa di mantenere la coerenza nei confronti di tutti i dispositivi presenti nel bus.

MESI è stato inserito nelle CPU "di massa" con i Pentium (i primi processori a gestire le cache write-back) mentre i 486 erano limitati al meno efficiente write-through.

L'uso di sistemi "snooping" (che "ascoltano" le comunicazioni sul bus ed invalidano la propria cache nel caso di scritture "altrove") o, in alcune implementazioni, "snarfing" (come le snooping, ma anziché invalidare il proprio valore recuperano quello scritto "altrove" e lo sostituiscono a quello che hanno internamente) genera una certa quantità di "messaggi" che viaggiano sul bus... anche per questa ragione in ambito multiprocessore un ruolo importante viene giocato dalla banda di interconnessione fra le CPU.

I processori AMD (dall'Athlon64 in poi) usano un evoluzione di MESI che si chiama MOESI (wow) e che introduce lo status "Owned" nel cui la cella in stato owned possiede la copia più recente di una locazione di memoria "dirty" e, su richiesta del bus, invia ne il contenuto.
Lo stato owned può passare da una cache all'altra ed in pratica si tratta di un evoluzione "snarfing" del classico MESI.

I processori Intel (i7, i5) invece hanno abbandonato solo di recente MESI per usare MESIF, un implementazione MESI (non c'eravate arrivati, vero ?) più adatta agli ambienti NUMA (Non-Uniform Memory Architecture, ne parleremo in seguito).
Nell'implementazione MESIF a cambiare rispetto a MESI è l'implementazione delle copie shared (che ora NON rispondono più ad eventuali snoop) e l'introduzione dello stato "Forward" che è "la copia più shared recente" e l'unica che risponde ad eventuali snoop.

La soluzione AMD sembra essere marginalmente superiore perché, al costo di un maggior traffico sul bus (dovuto ad uno snooping classico) una cella "dirty" viene scritta solo quando la sua ultima copia in cache viene espulsa mentre, di contro, la soluzione Intel potrebbe generare scritture multiple della stessa cella ma ha un minor overhead sul bus.
Com'è facile vedere AMD, che ha progettato bus capaci e robusti, si preoccupa di limitare il più possibile gli accessi in memoria mentre Intel preferisce puntare su un sistema che limiti il carico sui bus (in previsione di sistemi con molte unità) perdendo qualcosa negli accessi in memoria.

bravo

bump

Magari se lo legge giacche architettura degli elab. lo passa