• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
[ArcheLab] Lesson 06b
 

[ArcheLab] Lesson 06b

on

  • 305 views

Lezione 6 (seconda parte) del corso di Architettura degli Elaboratori, Informatica Industriale, Scuola di Scienze e Tecnologie, Università di Camerino

Lezione 6 (seconda parte) del corso di Architettura degli Elaboratori, Informatica Industriale, Scuola di Scienze e Tecnologie, Università di Camerino

Statistics

Views

Total Views
305
Views on SlideShare
305
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    [ArcheLab] Lesson 06b [ArcheLab] Lesson 06b Presentation Transcript

    • Architettura degli Elaboratori Livello di Microarchitettura (seconda parte) dott. Francesco De Angelis francesco.deangelis@unicam.it http://francescodeangelis.orgScuola di Scienze e Tecnologie - Sezione di Informatica Università of Camerino Aprile 2011 1 / 17
    • Predizione dei salti L’unità di prelievo legge parole consecutive e le invia all’unità di decodifica prima che siano effettivamente richieste Problema: tutto ciò è molto semplicistico! I programmi sono pieni di salti (condizionali e incondizionali) Il problema è nella natura della pipeline: prelievo di istruzioni successive senza sapere se sono quelle corrette. La posizione immediatamente successiva ad un salto si chaiama posizione di ritardo. alcune macchine a pipeline consentono la sua esecuzione! macchine molto più complesse non consentono ciò (es: Pentium II) 2 / 17
    • Predizione dei salti Salti condizionati più diffici da gestire (le prime macchine a pipeline rimanevano in stallo attendendo di conoscere la diramazione) letale per le prestazioni Utile predire se la diramazione sarà effettuata o meno, alcune assunzioni sono: effettuare i salti condizionali all’indietro (pressuppone un ciclo) non effettuare salti in avanti (si basa sul fatto che i salti in avanti avvengano per condizioni di errore, presupposto debole) In caso di predizione esatta tutto funziona a dovere, in caso di predizione errata occorre ripristinare lo stato del processore “come se non avesse eseguito le istruzioni” elevata complessità basata su registri "nascosti" per il ripristino dello stato 3 / 17
    • Predizione dinamica dei salti Aspetto molto importante per le prestazioni Un approccio è mantenere una tabella (in hw) della storia dei salti incontrati per successive analisi (a) un elemento per istruzione, indirizzo dell’istruzione e bit branch/no branch (funzionamento simile ad una cache, l’indirizzo del salto è il tag) Problema: predizione errata al termine dei cicli. 4 / 17
    • Predizione dinamica dei salti (b) due bit di predizione per risolvere il problema, si modifica la predizione dopo due predizioni rivelate errate (bit di ciò che si suppone occorra fare, bit per tener traccia di cosa si è fatto) (c) memorizza anche l’indirizzo del salto (che potrebbe non essere noto a priori ma calcolato da registri) 5 / 17
    • Predizione dinamica dei salti Altro approccio consiste nel tener traccia in un registro a scorrimento degli ultimi k salti condizionati indipendentemente dalle istruzioni associate. il registro viene confrontato con tutte le chiavi a k bit degli elementi di una tabella della storia. Se il confronto ha esito positivo, si usa la predizione. registro a scorrimento della storia dei salti tecnica strana ma funziona! 6 / 17
    • Predizione statica delle diramazioni Le tecniche viste sono dinamiche perchè effettuate durante l’esecuzione. Si adattano al comportamento del programma richiedono hw costoso e specializzato con grande complessità Alternativa: chiedere aiuto al compilatore modifica all’architetura con aggiunta di istruzioni che contengono un bit di predizione impostato dal compilatore Alternativa: “profiling”: esecuzione di una simulazione del programma per catturare il comportamento delle diramazioni. Comportamento fornito al compilatore che può specificare all’hw come comportarsi. 7 / 17
    • Esecuzione fuori sequenza e rinomina dei registri CPU moderne usano pipeline e sono superscalari Ciò comporta la presenza di una unità di fetch che preleva istruzioni prima che siano necessarie L’unità di decodifica assegna l’istruzione all’unità funzionale appropriata Questa esecuzione in ordine non ha sempre prestazioni ottimali Dipendenze RAW: una istruzione che richiede un valore calcolato da una istruzione precedente deve aspettare Salto di istruzioni “dipendenti” verso istruzioni che non lo sono (algoritmo di scheduling deve garantire l’equivalenza del risultato!!!) 8 / 17
    • Esecuzione fuori sequenza e rinomina dei registri Esempio: macchina con 8 registri (R0 . . . R7), istruzioni aritmetiche su tre registri, decodifica al ciclo n, esecuzione a n+1 e fine a n+2 (per l’addizione, a n+3 per la moltiplicazione). Due istruzioni lanciate per ciclo di clock. (istruzioni lanciate ed eseguite in ordine) 9 / 17
    • Esecuzione fuori sequenza e rinomina dei registri Dopo la decodifica , l’unità di decodifica deve decidere se lanciare o meno. Controllo dello stato dei registri, se ne è richiesto uno non ancora computato, l’istruzione attende. stato dei registri in una scoreboard: contatore per ogni registro delle istruzioni in esecuzione che lo richiedono come sorgente di un operando. Un bit per la richiesta come scrittura. se un operando è in fase di scrittura, non lanciare (dip. RAW) se il registro del risultato è in lettura, non lanciare (dip. WAR) se il registro del risultato è in scrittura, non lanciare (dip. WAW) 10 / 17
    • Esecuzione fuori sequenza e rinomina dei registri RAW: istruzione usa come operando risultato di un’altra istruzione non completata WAR/WAW: conflitto di risorsa, si cerca di scrivere un registro che l’altra istruzioni potrebbe non aver terminato di leggere/scrivere. Soluzione: registri temporanei Nell’esempio decodifica e fetch di bloccano in attesa di eseguire l’istruzione 4. Sarebbe possibile eseguire la 5, ma abbiamo il vincolo dell’esecuzione in sequenza per questa macchina 11 / 17
    • Esecuzione fuori sequenza e rinomina dei registri Attenzione: le istruzioni devono essere ritirate in sequenza (ritiro ordinato). Questo è necessario per poter stabilire che tutte le istruzioni siano state eseguite fino ad un certo indirizzo quando si effettua un interrupt (context switching). caratteristica nota come interrupt preciso il ritiro fuori sequenza delle istruzioni rende l’interrupt “impreciso” 12 / 17
    • Esecuzione fuori sequenza e rinomina dei registri Consideriamo l’esecuzione fuori sequenza, nuovo problema: l’utilizzo di un operando calcolato da una istruzione saltata non verrebbe notato usando la scoreborard. Soluzione: un bit per registro (non mostrato in fig.) per indicare i salvataggi effettuati dalle istruzioni in attesa e estensione delle regole per il lancio 13 / 17
    • Esecuzione fuori sequenza e rinomina dei registri Esaminiamo le istruzioni: (6) R1=R0-R2 (7) R3=R3*R1 (8) R1=R4+R4 L’istruzione (8) sovrascrive un valore calcolato in precedenza. Non c’è motivo di usare R1 per l’istruzione (6) Nuova tecnica: rinomina dei registri: viene usato un registro interno (segreto) S1 in modo da lanciare la’istruzione (6) in maniera concorrente alla (5). (6) S1=R0-R2 (7) R3=R3*S1 (8) S2=R4+R4 Si eliminano dipendenza WAR e WAW Con esecuzione fuori sequenza e rinomina abbiamo ottentuo un aumento delle prestazioni 14 / 17
    • Esecuzione speculativa Programmmi suddivisbili in blocchi elementari costituiti da una sequenza lineare di istruzioni con un punto di ingresso e una fine nessuna struttura di controllo (no if, no while) collegamento tra blocchi costituito da strutture di controllo permettere al riordinamento di superare il limite che separa i blocchi elementari 15 / 17
    • Esecuzione speculativa Iniziare operazioni costose comeLOAD prima possibile: slittamento L’esecuzione di codice prima di sapere se effettivamente sarà richiesto si chiama esecuzione speculativa necessario supporto hardware e del compilatore. E’ generalmente compito del compilatore scavalcare i limiti dei blocchi elementari l’esecuzione speculativa è pericolosa, può causare eccezioni senza che queste siano “volute” es: (if (x > 0) z = y/x). Per ovviare a ciò si usa uno speciale bit “poison bit” che segnala l’eccezione ma non la solleva Possibile uso distruzioni speculative (es: SPECULATIVE-LOAD) 16 / 17
    • Riferimenti [TAN] §4 - Livello di microarchitettura NOTA: Le slide sono tratte dalle slide degli scorsi anni e da diverse fonti disponibili in rete presso altre università e libri di testo. Quest’opera è stata rilasciata sotto la licenza Creative Commons Attribuzione-Non commerciale-Condividi allo stesso modo 2.5 Italia. Per leggere una copia della licenza visita il sito web http://creativecommons.org/licenses/by-nc-sa/2.5/it/ o spedisci una lettera a Creative Commons, 171 Second Street, Suite 300, San Fran- cisco, California, 94105, USA. 17 / 17