Introduzione al funzionamento dei processori!

[sku]

mio xp simpaticamente è morto

passa a linux!! PASSA A LINUX!!!! 8)

inoltra la rikiesta alla memoria ke provvederà a fornirla all'MMU ke la passa poi al processore.

ma e' cosi' necessario che i dati passino per l'MMU prima di arrivare alla CPU???

sku

[thrantir]

certo ke devono passare x l'MMU

In realtà x ogni dato rikiesto sia una istruzione o un dato vero e proprio l'MMU deve dare anke un'esito dell'operazione al processore, cioè gli deve dire, ok la parola rikiesta è arrivata oppure generare un'eccezione

[thrantir]

ragazzi ke vi è successo, l'ultimo pezzo vi ha storditi? oppure nn avete nessun dubbio?

[Imrik]

se devo essere sincero nn sono sicuro di aver capito tutto.

ma sono sicuro di aver capito "in generale".. poi magari mi dovrei anke rileggere quando ho tempo i post precedenti xkè li ricordo ma nn tutti..

nn ti faccio nessuna domanda dato ke nn ne ho una precisa.
continua così, stai facendo 1 buon lavoro!

[azarius]

thrantir una cosetta.... rileggendo ho letto la storiella delle pagine....

ma le pagine che tolgo dagli anelli che fine fanno???????????? se già quelle esistenti occupano la nostra memoria...

[thrantir]

ci possono essere due possibilità:

1) le pagine sono state modificate mentre stavano in memoria principale, in questo case vanno sovrascritte alla loro copia principale ke sta sull'hard disk

2) le pagine nn sono state modificate, allora le possiamo semplicemente cancellare dalla memoria xkè ne abbiamo una copia valida sull'hard disk

[azarius]

ok grazie

[sku]

ci possono essere due possibilità:

1) le pagine sono state modificate mentre stavano in memoria principale, in questo case vanno sovrascritte alla loro copia principale ke sta sull'hard disk

2) le pagine nn sono state modificate, allora le possiamo semplicemente cancellare dalla memoria xkè ne abbiamo una copia valida sull'hard disk

si e no....

si puo' anche optare per la modalita' write through che updata l'hd ogni volta che modifica la ram....

[thrantir]

vero, ma il mio intento è nn complicare le cose enumerando troppe tecnike 8)

in effetti ho già in mente un post sulle gerarkie di memoria ma prima credo ke sia indispensabile introdurre la cache

[thrantir]

Forse credevate ke vi avessi abbandonato... beh, eccomi qui di nuovo!

Devo dire ke arrivati a questo punto sono un po incerto su come proseguire... ho deciso ke x ora vi scriverò questo post in cui faremo una specie di ripasso generale introducendo cmq qualke cosa ke ci sarà molto utile dopo quando faremo un salto tecnologico

Vediamo quindi di capire un po meglio l'esecuzione di un programma da parte del processore.

Ora siete tutti + consapevoli di come sia strutturato un programma in istruzioni e dati e di cosa voglia dire farlo eseguire al processore. Per sempplicità supporremo ke le istruzioni siano sempre all'inizio del programma (quindi iniziano nella pagina zero!) mentre i dati e le altre cose (la tabella di rilocazione!) siano in pagine successive...

Quindi all'inizio del nostro programma ci sono una serie di pagine di istruzioni, ora pensiamo ke queste istruzioni siano tutte numerate dalla 0 alla n-1 dove n è il numero delle istruzioni. Vi ricordo ke ogni istruzione occupa nel nostro modello una parola quindi in pratica stiamo numerando n parole ke iniziano dalla pagina 0 del programma

Ora diciamo ke il nostro processore sa "contare" le istruzioni... ke ce ne facciamo di ciò?
Per capire bene dovete aver presente come funziona l'istruzione di LOAD e quello ke succede nelle istruzioni di salto... ora vediamo se riuscite a seguirmi: quando il processore rikiede una nuova istruzione quello ke fa è sommare all'indirizzo di memoria (logico!) dove iniziano le istruzioni (ke x noi è la riga 0 della pagina 0) il numero dell'istruzione ke deve eseguire... quindi se deve eseguire l'istruzione numero 15 quello ke fa è rikiedere la parola numero 15 a partire dalla parola 0 della pagina 0...
Per fare questo il procesore possiede un registro ke in genere viene kiamato IC (ke vuol dire Instruction Counter) ke viene aumentato di 1 ogni volta ke dobbiamo passare all'istruzione successiva...
Spero ke x voi sia kiaro tutto questo... ora dovreste anke capire in cosa consiste l'istruzione di salto, è molto semplice: invece ke aumentare di 1 il registro IC noi ci mettiamo il numero dell'istruzione a cui vogliamo saltare e il gioco è fatto!

Ora dovreste anke capire meglio i vantaggi della memoria virtuale: il processore sa ke le pagine dove stanno le istruzioni sono le prime e quindi la base da cui contare per avere l'istruzione desiderata è sempre la pagina 0... non importa ke poi in memoria le pagine siano tutte incasinate xkè della traduzione dell'indirizzo se ne preoccupa la nostra MMU quindi il processore procede tranquillo... questo vantaggio si ha anke x altre cose tipo quando si vuole rikiamare tutti gli elementi di un vettore (x ki nn se lo ricorda è una lista di elementi tutti uguali) se questo vettore è grande e tutti gli elementi nn ci stanno in una pagina x il processore non è un problema! lui sa ke il vettore comincia nella pagina (logica!) numero tot e a partire da quella pagina rikiama prima l'elemento numero 0, poi il numero 1 ecc...

La cosa + importante di questo post è capire ke esiste un registro, il registro IC, ke in pratica è il riferimento del processore x capire quale è l'istruzione da eseguire... tenetelo bene a mente xkè comparirà prossimamente quando parleremo di unità Input Output e interruzioni

Ciao alla prox!

[thrantir]

Direi ke siamo protni a inserire un'altro pezzo del nostro puzzle, oggi vi parlo di periferike... intanto vediamo di capire cosa sono e secondo quali principi funzionano...

Una periferica è un dispositivo "esterno" al processore ke generalmente svolge una particolare funzione... al 95% le periferike si occupano di operazioni di Input-Output. Esempi di periferike sono il mouse, la tastiera, il monitor, la stampante ecc... Come potete rilevare dalla vostra esperienza diretta per interfacciarsi con queste periferike spesso è necessario avere qualcosa ke fa da intermediarioo meglio, in gergo, controllore, come la skeda video, la skeda audio... in realtà anke x tastiera e mouse c'è un controllore ma siccome è incorporato nella nostra mobo nn ce ne accorgiamo...

Xkè servono i controllori? In effetti hanno molteplici scopi, vi dico i due ke secondo me sono i principali:

- Sono loro ke si preoccupano di comunicare con il processore: il processore ha bisogno di essere contattato secondo un "linguaggio" standard, quindi in questo modo la periferica può "parlare" in un altro linguaggio e il controllore si preoccupa di tradurre

- Possono svolgere delle elaborazioni sui dati scambiati con il processore invece ke farle eseguire al processore stesso... se pensate all'evoluzione delle skede audio e delle skede video vi renderete conto ke ora diverse funzionalità sono fatte eseguire ai controllori invece ke al procio con tanto di guadagnato sul carico di lavoro del processore

sarebbe comodo ke il processore fosse collegato con un collegamento a parte (in gergo si dice "dedicato") ad ognuno dei controllori ma questo non è fattibile... siccome il processore comunica con i controllori sempre con il solito formato (con parole) dovrebbe avere 32 collegamenti per ogni unità... cioè 32 pin per ogni unità, vi immaginate come diventerebbe il proessore? comincerebbe a sembrare una coperta...
Invece la soluzione, ke tutti voi conoscete, e l'utilizzo di una risorsa condivisa tra il processore e tutti i controllori ke viene kiamata "bus"...
Sul bus passano i messaggi di tutti, processore, controllori ecc.... siccome però può usarlo solo uno per volta ecco ke siamo approdati ad una delle problematike classice dell'informatica, una problematica ke compare ogniqualvolta c si trova davanti ad una risorsa condivisa tra più entità. Questa problematica si kiama "arbitraggio" e consiste nell'avere un modo per dire ki di volta in volta può usufruire della risorsa condivisa (ke nel nostro caso è il bus)... abbiamo quindi bisogno di un arbitro del bus... abbiate ancora un po di pazienza, nel prossimo post diremo ki arbitra e come lo fa!

[thrantir]

Ok, ora tutti bene attenti ke si parla di una cosa ke molti hanno sentito ma molti meno sanno cosa sia e come funzioni... sto parlando delle interruzioni (o interrupt detto all'inglese!)

allora, il nostro problema è ke abbiamo questo bus e vogliamo ke sia usato da uno per volta... se non facessimo così sarebbe come se + presone parlassero al telefono contemporaneamente utilizzando la stessa linea, invece ke scambio di parole ci sarebbe solo rumore incomprensibile!

Quindi dobbiamo spremerci x trovare un modo di concedere l'uso del bus di volta in volta ad uno solo (sia esso processore o controllore)... la scelta del modo di concedere l'uso del bus si dice tecnicamente "decidere la politica di arbitraggio".... ovviamente il protagonista di questo discorso è il fantomatico "arbitro"!

le tecnike di arbitraggio sono varie, alcune vanno meglio di altre in certe situazioni, alcune sono studiate apposta x certi sistemi... nn starò a dirvi ora quali sono le + diffuse e come funzionano, magari un'altra volta... la soluzione ke vi descrivo adesso viene detta "on demand"

Come dice la parola questa tecnica sunziona "su domanda", ke vuol dire? Quando un'unità ha bisogno di utilizzare il bus manda un segnale a un dispositivo apposito... questo dispositivo si preoccuperà di decidere tra tutti quelli ke hanno fatto rikiesta ki utilizzerà il bus. La rikiesta di utilizzare il bus si kiama "interruzione" e il dispositivo ke gestisce le interruzioni si kiama "unità di gestione delle interruzioni" (ke fantasia xò... )

Per motivi vari questa unità è "incorporata" nel processore, ora vi descriverò per bene cosa avviene in caso di interruzioni:

Supponiamo ke un'unità abbia bisogno di usare il bus per comunicare con il processore (x ora non preoccupatevi di cosa possono volersi "dire")... questa unità manda il segnale di interruzione e attende ke la sua rikiesta sia accettata... se ci sono + interruzioni l'unità incorporata nel processore ne sceglie una in base a una certa politica. Il processore nel frattempo come ben sappiamo sta eseguendo un programma... bene, appena finito di eseguire un'istruzione prima di rikiamare la prossima controlla se per caso ci sono interruzioni... se ci sono interruzioni si avvia una fase detta "fase di trattamento delle interruzioni". Durante questa fase il processore comunica con l'unità... quando il discorso è finito l'unità rilascia l'uso del bus (ke diventa quindi disponibile di nuovo) e riprende l'esecuzione del programma ke era stata interrotta dall'....interruzione!

X ora leggetevi x bene questo post, nel prossimo scenderemo un po + in dettaglio su cosa succede durante la fase di trattamento interruzione, come fa il processore a riprendere l'esecuzione del programma dal punto in cui è stato interrotto ecc.... presto introdurremo i nostri cari amici driver!

[Siva]

Gente, visto che vi bedo fomentati sull'argomento e siccome non ho tempo per leggere tutti i post vi consiglio di dare un okkio a Giobe2000, dove un santo omino spiega per filo e per segno la base di funzionamento di memorie e cpu, non che un esauriente spiegazione di un paio di linguaggi asm.
Cmq almeno per quello che ho visto avete trattato fino a questo punto solo le architetture basate sul modello Von Neumann, ma forse per chi è alle prime armi potrebbe essere interessante vedere il funzionamento delle mcu risk architettura Harvard che aiuta la comprensione delle operazioni bit a bit dato che molte mcu risk di uso comune in elettronica lavorano a 8 o 16 bit.
Buon lavoro e spero di avere un pochino di tempo per leggermi tutti i post.

[thrantir]

Scusatemi la latitanza nel proseguire, ho avuto una settimana parekkio piena!

Riprendiamo il discorso, ampliamo quello ke abbiamo detto sulla comunicazione tra il processore e le unità di I/O...

E' capitato a tutti voi in ognuna delle installazioni ke avete fatto di arrivare alla fase di piazzare nel vostro sistema i driver delle periferike... ma vi siete mai kiesti xkè senza questi driver le periferike o funzionano a un quarto o non funzionano del tutto? Probabilmente nn ve lo siete mai kiesto e avete accettato x fiducia ke fossero indispensabili xkè il vostro sistema funzionasse...

Ebbene, dovete sapere ke ogni periferica piazzata nella vostra configurazione x lavorare deve avere "qualcuno" capace di rikiedere le operazioni ke la periferika deve svolgere nel "linguaggio" giusto. Questo "qualcuno" è proprio il driver della periferica! Il driver è un programma come gli altri ke xò x le sue caratteristike particolari si piazza un livello sotoo le applicazioni utente vere e proprie (come il word, l'outlook ecc...) xkè è in realtà "un'estensione" del sistema operativo (magari un giorno si potrà fare una discussione + particolareggiata su questo concetto di estensione)...
Quando accendete il computer il vostro sistema operativo ha bisogno di farsi una tabellina con tutte le corrispondenze tra le periferike e il driver associato, xkè?

Torniamo al post precedente e precisamente al momento in cui l'unità ke ha inviato l'interruzione ha avuto accesso al bus. La prima cosa ke l'unità dirà al processore attraverso il bus è il proprio nome. Il processore ha necessariamente bisogno di questa informazione xkè tramite il nome dell'unità (ke in questo caso è un numero ke identifica l'unità) è capace di ritrovare il driver associato a questa unità. Questo passaggio è indispensabile xkè solo il driver dell'unità sa come "colloquiare" con l'unità in questione. una volta trovato il driver giusto questo va in esecuzione e comunicando con l'unità "scopre" il motivo dell'interruzione e si preoccupa di fare tutto ciò ke serve.

Rivediamo quindi come funziona il meccanismo dell'interruzione:
- Una unità rikiede un'interruzione al processore ke nel frattempo sta eseguendo un prog qualsiasi
- L'arbitro del bus segnala l'interruzione al processore ke al momento giusto la rileverà
- Quando il processore rileva l'interruzione deve innanzitutto salvare da qualke parte il contenuto del registro IC (vi ricordate di questo registro?) e in questo modo potrà ripartire nell'esecuzione del programma esattamente da dove è stato interrotto
- Salvato il contenuto di IC il processore invia tramite il bus una comunicazione all'unità ke ha kiesto l'interruzione x farle sapere ke ora può inviare le sua rikiesta
- L'unità si identifica mandando sul bus il proprio nome (identificativo numerico)
- Il processore consulta la tabella di corrispondenza dei driver scoprendo qual'è quello relativo all'unità in questione
- Viene fatta una jump (ve ne ricordate?) alla prima istruzione del driver
- A questo punto il driver va in esecuzione e si preoccuperà di servire l'unità e, quando finirà, di far riprendere l'esecuzione del programma ke era stato interrotto.

Ora quindi avete un'idea di come funziona l'interazione tra le diverse unità e il processore. Quello ke vi ho descritto succede continuamente mentre state daventi al computer, infatti il driver della skeda video, della skeda audio, del disco sono attivi costantemente xkè molte delle operazioni ke facciamo comunemente utilizzano queste periferike.

Ci risentiamo nel prossimo post ke sarà breve e parlerà del DMA
Ciao a tutti!

[thrantir]

rieccomi come promesso per parlarvi del DMA

Questo è in realtà un argomento + semplice id quelli ke abbiamo visto finora...

ora sapete ke ogni unità parla con il processore tramite il suo driver e in questo modo apporta le sue capacità al sistema. Pensate ora all'hard disk, anke lui deve sottostare a questo funzionamentom xò in certi casi noi vorremmo avere un'alternativa: immaginate di dover trasferire un grosso quantitativo di dati dall'hard disk alla ram (ricordatevi ke se i dati nn stanno nella ram il processore nn ci può accedere, per esempio quando c'è un fault di memoria la pagina mancante in memoria viene prelevata dall'hd e messa nella ram). Siccome il bus ci permette di trasferire una parola alla volta noi dovremmo trasferire ogni parola dall'hd al processore il quale poi si dovrebbe preoccupare di scriverla nella memoria (per esempio con una LOAD). Vi renderete conto ke questo è parekkio pesante, prima di tutto xkè dover passare dal processore rende il trasferimento + lungo, secondo xkè il processore rimane occupato a fare questo invece di eseguire altri processi!
Quindi quello ke vogliamo è poter dire all'hd "trasferisci questi file per conto tuo e avvisami quando hai finito"... cosa ci serve x fare questo?
Innanzitutto ci serve ke l'hd sia collegato alla memoria direttamente, poi ci serve un modo x permettere all'hd di dire al processore "ho finito".

Partiamo dal secondo, se siete stati attenti sapete già la risposta: l'hd manda un'interruzione al processore e quando il processore tratterà quella interruzione scoprirà ke l'hd ha finito.

Invece la necessità di un collegamento diretto tra hd e memoria rikiede un po di comprensione in +... intanto riflettete sul fatto ke ci potrebbe essere + di un hd e ke nn solo gli hd hanno la necessità di essere collegati direttamente alla memoria. La cosa migliore è ke esista un canale di comunicazione condiviso tra tutti quelli ke possono aver bisogno di accedere alla memoria... vi ricorda niente questo? E' proprio la stessa situazione ke avevamo con il bus ke collega il processore alle unità di I/O...
Quindi le prblematike da affrontare sono le stesse, con una sempplificazione: nel caso del processore dovevamo tenere conto ke il processore è sempre impegnato a eseguire qualcosa quindi esiste un'unità a parte ke rileva le interruzioni e ne sceglie una da servire, invece in questo caso l'arbitraggio sarà controllato direttamente da una unità apposita, appunto il controllore DMA. Questo controllore deciderà di volta in volta ki può scrivere in memoria

Abbiamo quindi realizzato il nostro DMA: infatti DMA è l'acronimo di DIrect Memory Access!

Bene, il nostro piccolo sistema didattico prende piano piano forma... nel prossimo post miglioreremo le prestazioni del nostro processore introducendo la famigerata "memoria cache"

ciao a tutti!