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