Architetture I Lez. 17-18 Il processore II parte Architetture degli Elaboratori I © Danilo Bruschi Controller a ciclo unico • Abbiamo così realizzato un conotrller che in un solo ciclo di clock è in grado di eseguire una qualunque delle istruzioni considerate • Il ciclo di clock dovrà essere dimensionato sull’istruzione più lenta • Si tratta di un’implementazione molto inefficiente A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Dimensionamento clock • Assumiamo ritardi nulli per multiplexer, unita’ di controllo, estensione del segno, accesso PC, shift left, linee di connessione e assumiamo i seguenti tempi: • 100ps for register read or write • 200ps for other stages A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Problemi singolo ciclo • La dimensione del ciclo di clock è determinata dall’istruzione più lunga • Lw nel nostro caso e’ load, ma cosa succederebbe se considerassimo anche istruzioni floating point? • Perdita di tempo • molte istruzioni possono essere eseguite in un tempo minore • Le risorse che devono essere usate piu’ di una volta nello stesso ciclo devono essere duplicate • Spreco di hardware/chip area A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Possibili soluzioni • Usare un periodo di clock variabile per ogni tipo di istruzione • Soluzione non pratica • Approccio Multiciclo • Usare un tempo di ciclo più piccolo… • Saranno necessari più cicli per completare l’esecuzione di istruzioni diverse • dividendo l’esecuzione in passi • eseguendo un singolo passo per ciclo A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Confronto Single-cycle • Ogni istruzione richiede per essere eseguita un ciclo di clock • Esiste un unico insieme di segnali di controllo condiviso da tutte le istruzioni • Il periodo di clock è determinato dall’istruzione che richiede più tempo per essere eseguita A.A. 09/10 Multi-cycle • Ogn istruzione è eseguita in più cicli di clock • Esiste un insieme di segnali di controllo diversificato per ciclo e per istruzione • Il periodo di clock è dimensionato sullo stadio più lento Architetture degli Elaboratori I © Danilo Bruschi +4 1. Instruction Fetch A.A. 09/10 ALU Data memory rd rs rt registers PC instruction memory I passi imm 2. Decode/ Register Read 3. Execute 4. Memory 5. Reg. Write Architetture degli Elaboratori I © Danilo Bruschi Passo 1 • Stage 1: Instruction Fetch • Passo comune a tutte le istruzioni • Carica l’istruzione da eseguire dalla memoria (cache) • all’interno del datapath In questo passo si incrementa anche contemporaneamente il valore del Program counter (PC = PC + 4, negli esempi sinora visti; nel caso di architetture più complesse, questa operazione è molto più elaborata) A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Passo 2 • Stage 2: Instruction Decode • Dopo aver caricato l’istruzione si deve • • A.A. 09/10 provvedere al recupero dei dati per la sua esecuzione (decode all necessary instruction data) Attraverso il codice operativo si determina il tipo di operazione e gli operandi di cui necessita Vanno poi letti tutti i dati dai registri coinvolti • Nel caso di add, due registri • Nel caso di addi, un registro • Nel caso di jmp non è richiesto alcun registro Architetture degli Elaboratori I © Danilo Bruschi Passo 3 • Viene attivata la ALU per compiere le diverse operazioni che possono essere richieste dall’istruzione in esecuzione A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Passo 4 • Memory Access • È un passo che viene eseguito solo nel caso di lw e sw, le istruzioni che non usano la memoria, rimaranno in idle, oppure termineranno al passo 3 A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Passo 5 • Register Write • Molte istruzioni scrivono il risultato della loro computazione in un registro e svolgeranno questa operazione in questo passo Esempi: istruzioni aritmetiche, logiche, shift, lw • • Ancora una volta le istruzioni che non devono usare i resistri in scrittura non faranno niente in questo ciclo o termineranno al ciclo precedente? A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Esempio • add $r3,$r1,$r2 # r3 = r1+r2 • Passo 1: fetch dell’instruzione e incremento PC • Passo 2: decodifica, che determina che ci • • • A.A. 09/10 troviamo di fronte ad una add, quindi lettura di $r1 e $r2 Passo 3: somma dei due valori letti al passo precedente Stage 4: idle (non c’è niente da scrivere in memoria) Stage 5: scrivi il risultato del passo 3 nel registro $r3 Architetture degli Elaboratori I © Danilo Bruschi reg[1]+reg[2] reg[2] ALU Data memory 2 reg[1] imm add r3, r1, r2 +4 3 1 registers PC instruction memory Example: ADD Instruction A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Esempio • sw $r3, 17($r1) • Passo 1: fetch dell’istruzione e incremento PC • Passo 2: decode che determina che siamo di • • • A.A. 09/10 fronte ad una sw, e conseguente lettura dei registri $r1 e $r3 Passo 3: somma 17 a $r1 Stage 4: scrive il valore di $r3 (retrieved in Stage 2) nella locazione di memoria il cui indirizzo è stato calcolato al passo 3 Passo 5: idle (niente da scrivere nei registri) Architetture degli Elaboratori I © Danilo Bruschi imm 17 A.A. 09/10 reg[1] reg[1]+17 reg[3] ALU Data MEM[r1+17]<­r3 memory 3 SW r3, 17(r1) +4 x 1 registers PC instruction memory Example: SW Instruction Architetture degli Elaboratori I © Danilo Bruschi Il controller multiciclo • L’implementazione del controller a ciclo unico poteva essere effettuata basandosi esclusivamente su circuiti combinatori • Nel caso del controller a ciclo multiplo, i segnali di controllo assumono valori diversi in funzione del passo in cui si trova l’esecuzione dell’istruzione, in questo caso è quindi necessario ricorrere a circuiti sequenziali che possono essere realizzati in due modi: • Attraverso gli automi e poi logica cablata • Microprogrammati A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Schema generale di un controller multiciclo A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Schema generale dell’automa Start Instruction fetch/decode and register fetch Memory access instructions A.A. 09/10 R-type instructions Branch instruction Jump instruction Architetture degli Elaboratori I © Danilo Bruschi L’automa A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Microprogrammazione • Un modo alternativo per specificare e realizzare un controller • Automi • Stati cerchi • Segnali di controllo all’interno degli stati • Difficili da usare per sistemi complessi • L’alternativa, trattare il problema della specifica di un controller come un problema di programmazione A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Microprogrammazione • I segnali di controllo sono attivati attraverso l’esecuzione di una sequenza di micor istruzioni • Un microprogram counter and un pò di circuiti addizionali vengono usati per eseguire la sequenza di microistruzioni • Il controller nei casi di Complex Instruction Set Architecture (CISC) è solitamente implementato usando la microprogrammazione A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Microprogramma: esempio • Ad ogni ciclo di clock viene eseguita una microistruzione che specifica il valore dei segnali di controllo Label Alu Fetch Src1 Src2 Reg Add Pc 4 Read pc Alu Add Pc Extshft Read Mem1 Add A Alu Next? +1 Dispatch 1 Extend Dispatch 2 Lw2 Read alu Write mdr A.A. 09/10 Memory Pcwrite +1 fetch Architetture degli Elaboratori I © Danilo Bruschi Microcode controller (fig. 5.47) Microcode storage Datapath control outputs Outputs Input 1 Microprogram counter Sequencing control Adder Address select logic A.A. 09/10 Inputs from instruction register opcode field Architetture degli Elaboratori I © Danilo Bruschi Stato dell’arte • Specifica dei controller • FSM – poc adeguati per architetture complesse • Microprogrammazione – funziona • VHDL/Verilog – il sistema preferito A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Pipeline Source: http://www.ece.arizona.edu/~ece462/Lec03-pipe A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Pipeline di istruzioni A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eccezioni e Interrupt A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Sistema operativo • Un programma presente su ogni sistema che: • fornisce servizi a tutte le applicazioni che usano un calcolatore • gestisce tutte le risorse di un calcolatore: memoria, CPU, Dischi, Video, ecc. Pg1 Pg2 Pg3 Pg4 Sistema operativo A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Istruzioni privilegiate • Esiste un sottoinsieme delle istruzioni eseguibili da un processore, che possono essere eseguite solo dal sistema operativo e da nessun altro programma • Ad esempio: • Tutte le istruzioni per comandare le periferiche di I/O (stampanti, dischi, mouse, ecc.) • Manipolare alcuni registri del processore • La CPU deve quindi sapere quando sta eseguendo il sistema operativo, per attivare anche l’esecuzione delle istruzioni privilegiate A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi User vs. Kernel Mode • Tutti I processori moderno prevedono quindi almeno due modalità di esecuzione: • User mode: nessuna istruzione privilegiata può essere eseguita • Kernel mode: tutte le istruzioni possono essere eseguite • I programmi scritti dagli utenti sono eseguiti con il processore in user mode • Il sistema operativo viene eseguito in kernel mode A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi User Vs. Kernel mode • La modalità con cui il processore sta operando è indicata dal valore di un particolare bit, chiamato bit di stato presente in un registro di controllo • la CPU controlla il valore di questo bit prima dell’esecuzione di ogni sitruzione privilegiata A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi OS • Il sistema operativo è un programma particolarmente complesso • Per avere un idea della sua complessità si considerino i seguenti dati espressi in SLOC (Source Line of Code) • • • • • Windows NT (1993): 6 Million Windows XP: ~50 Million Windows Vista: ~XP + 10 Max OS X 10.4: ~86 Million Ubuntu distribution: > 230 Million • But tons of things are not part of the OS • Kernel 2.6.29: 11 Million A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eventi • Il sistema operativo può essere visto anche come il gestore di eventi inattesi • Evento inatteso, un qualunque fatto che si può verificare durante l’esecuzione di un programma e che non è gestito dal programma stesso • A fronte di un evento inatteso, il sistema operativo prende il controllo del sistema e gestisce l’evento • All’interno del sistema operativo sono definite delle porzioni di codice, chiamate handler, che sono eseguite in kernel mode e gestiscono ogni tipo di evento A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eventi • Esistono due grosse categorie di eventi: gli interrupt e le eccezioni • Gli interrupts sono collegati ad eventi causati da dispositivi esterni al processore • Tipicamente dispositivi di I/O che devono comunicare al sistema operativo qualche avvenimento • Le eccezioni accadono invece durante l’esecuzione di un’istruzione • Un tipo speciale di eccezione è la system call • Un meccanismo attraverso il quale un programmatore può cheidere esplicitamente dei servizi al sistestema operativo Architetture degli Elaboratori I A.A. 09/10 © Danilo Bruschi La gestione degli eventi • Quando si verifica un evento il processore deve interrompere l’attività in corso e trasferire il controllo al sistema operativo • Il sistema operativo potrà poi decidere: • Se terminare il programma in esecuzione • Semplicemente notificare al programma il verificarsi di una certo evento A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Gestione degli eventi • Ad ogni evento è associato un numero • Il sistema operativo costruisce un vettore degli interrupt, cioè un array che contiene per ogni posizione l’indirizzo della routine deputata a gestire quell’evento • Quanto si verifica l’evento numero i viene richiamata la routine che si trova all’indirizzo presente in interrupt_vector[i] • Prima che ciò avvenga è però necessario salvare il contesto del programma interrotto A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eccezioni • Durante l’esecuzione di un programma da parte del processore si possono verificare delle situazioni non prevedibili in fase di programmazione, che: • Possono impedire le normale esecuzione del programma • Compromettere il risultato finale • Chiamiamo questi eventi eccezioni A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Le cause • Le principali cause sottostanti un’eccezione sono: • • • • • • Overflow aritmetico Codice operativo non lecito (illegal opcode) Instruction fetch page fault Codice operativo privilegiato Data page fault Segmentation fault A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Come si rilevano le eccezioni • L’eccezione può essere rilevata solo all’interno del controller o del datapath durante l’esecuzione di un’istruzione • Una volta rilevata è necessario che il controller effettui una serie di passi necessari alla gestione dell’evento A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Come si rilevano le eccezioni A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Implementing Exceptions • Nel nostro caso le eccezioni rilevabili sono due • 0 undefined instruction • 1 arithmetic overflow • Quando il sistema entra negli stati relativi ad una eccezione per prima cosa il controller provvede a memorizzare il tipo di eccezione riscontrata • Dopodiché si sospende l’esecuzione del programma corrente • Si cerca di capire il tipo di errore che si e verificato per poi decidere se riprendere il programma interrotto o sospenderlo definitivamente (ABORT) A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Le cose da fare 1. Sospendere l’esecuzione del programma in corso e avviare l’esecuzione di una routine del sistema operativo che sia in grado di comprendere quello che è accaduto 2. Riprendere il programma sospeso oppure interromperne l’esecuzione A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Sospendere un programma • Per sospendere un programma ed avviarne uno nuovo è sufficiente mettere nel PC (EIP) l’indirizzo della prima istruzione del nuovo programma • Se si è verificata l’eccezione i-esima • PC Interrupt_Vector [i] • In alcune architetture invece del vettore di interrupt si usa un indirizzo fisso di memoria A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Sospendere il programma • L’esecuzione di questa istruzione comprometterebbe però ogni possibilità di poter riprendere, successivamente, l’esecuzione del programma interrotto • Prima di effettuarla è quindi necessario intraprendere opportuni accorgimenti per salvare le informazioni che ci possono tornare utili in una fase successiva A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eccezioni: Hardware • Salva le informazioni che consentono di risalire ai motivi che hanno causato l’eccezione in appositi registri • Cambia la modalità di esecuzione in kernel • Disabilita gli interrupt • Salva il valore del PC e di altri registri del datapath • Salta ad un indirizzo specifico (MIPS: 0x80000080) oppure ad un indirizzo presente nel vettore di interrupt A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Eccezioni: Software • Salva ulteriori registri • Determina il tipo di eccezione e salta al gestore specifico per quella eccezione • Gestisce l’eccezione specifica • Se decide che il programma sospeso può essere ripreso: • Ripristina i registri salvati • Ripristina la modalità di esecuzione precedente (user vs. supervisor) • Riabilita gli interrupt • Riprendi il programma da dove sospeso • Altrimenti • Manda in esecuzione un apposito modulo del SO A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Interrupt • La presenza di interrupt viene segnalata al processore da un apposito circuito PIC (Programmable Interrupt controller) che attiva elettricamente un piedino dedicato del processore • Pur essendo eventi concettualmente diversi dalle eccezioni (asincroni vs. sincroni) sono gestiti a livello hardware nello stesso modo • L’unica diversità è la procedura di rilevazione: la presenza di interrupt viene rilevata prima di iniziare il ciclo di esecuzione di un’instruzione A.A. 09/10 Architetture degli Elaboratori I © Danilo Bruschi Interrupt INTERRUPT = 1 FETCH INTERRUPT DEC LW A.A. 09/10 SW BEQ R-type Exc.1 Architetture degli Elaboratori I © Danilo Bruschi