Re: kernel piu' grosso al "crescere" della CPU
hcnaint ha scritto:
On Wed, Jun 01, 2005 at 06:54:45AM -0400, Premoli, Roberto wrote:
A parita' di condizioni, con la sola modifica della cpu di destinazione,
la dimensione finale del kernel monolitico "cresce".
Es:
compilato per 386: 1085K
compilato per P4: 1115K
"Pero` magari cambia l'allineamento dei dati e delle istruzioni, quindi
per avere piu` performance mette piu` roba ad indirizzi multipli di
qualcosa."
ho letto in passato vari articoli sull'argomento, cerco di riassumere
quello che mi ricordo e semplificandolo il più possibile ... non sono
sicuro che sia tutto corretto perché non seguo più l'argomento ormai da
un sacco di anni (dal tempo dei 386 e forse i primi 486/pentium).
In pratica per eseguire una semplice operazione in linguaggio macchina
vengono eseguite più parti semplici tra loro indipendenti:
* fetch (caricamento istruzione)
* decode (decodifica istruzione)
* execute (esecuzione dell'istruzione)
* write (scrittura risultati)
Se non ricordo male le prime CPU facevano queste operazioni in sequenza
per ogni istruzione, quindi prima di iniziare il processamento
dell'istruzione 2, occorreva che l'istruzione 1 fosse stata totalmente
processata.
Da una certa versione di CPU in poi invece si è iniziato a far
funzionare in parallelo queste sotto-istruzioni che sono tra loro
indipendenti (== possono funzionare in parallelo).
In pratica ad ogni passo vengono eseguite:
passo1: fetch ISTR1
passo2: decode ISTR1 e fetch ISTR2
passo3: execute ISTR1, decode ISTR2 e fetch ISTR3
...
Però c'è un grosso problema: l'istruzione ISTR2 potrebbe essere per
esempio un jump condizionato dipendente dal risultato dell'ISTR1 quindi
in teoria ISTR2 dovrebbe attendere la fine di ISTR1 prima di poter
essere decodificata/eseguita.
Per risolvere questi problemi ci sono più soluzioni (se non ricordo male
vengono anche applicate contemporaneamente) tra cui:
* inserire delle nop (no operation) tra istruzioni assembler successive
* cercare di prevedere il risultato dell'istruzione precedente in modo
che se si è azzeccato, allora al temine dell'ISTR1 si avrà che l'ISTR2 è
già stata eseguita ...
* ...
Ora non vorrei dire una gran cavolata (se già non ne ho dette qui
sopra), ma mi sembra di ricordare che un 486 non è altro che un 386 che
è in grado di eseguire due istruzioni contemporaneamente e quindi usa
tecniche di previsioni, inoltre negli eseguibili sono inseriti delle nop
per minimizzare i cicli di clock necessari ... o forse questo discorso
era applicato ai pentium (infatti i primi pentium dovevano avere i
banchi a coppie perché le RAM non permettevano accessi multipli ...)
Ciao
Davide
--
Linux User: 302090: http://counter.li.org
Prodotti consigliati:
Sistema operativo: Debian: http://www.it.debian.org
Strumenti per l'ufficio: OpenOffice.org: http://it.openoffice.org
Database: PostgreSQL: http://www.postgres.org
Browser: FireFox: http://texturizer.net/firefox
Client di posta: Thunderbird: http://texturizer.net/thunderbird
Enciclopedia: wikipedia: http://it.wikipedia.org
--
Non autorizzo la memorizzazione del mio indirizzo di posta a chi usa
outlook: non voglio essere invaso da spam
Reply to: