Newsgroup: it.comp.hardware.cpu
Titolo: Tecnico - Domanda stupida (credo...)

Ho un dubbio atroce....
MA quando arriva un interrupt al processore e il sistema operativo
interrompe il processo in corso per passare alla gestione dell'interrupt,
tutte le istruzioni di prefetch (credo si chiamino cosě.. insomma quelle per
la previsione dei salti) dove vanno a finire???
Ad ogni interruzione viene salvato il modo e l'indirizzo di ritorno, ma ste
istruzioni?
Altra cosa: l'istruzione in corso viene eseguita fino in fondo, ok..
Ma una pipeline a 20 stadi come mi pare che sia quella del P4, butta via
istruzioni ad ogni interrupt?
Mi sa che mi sto perdendo qualcosa :((
Dai guru, illuminatemi :)
--
Say NO to the Wanker!
Say NO to AR!
Campagna per il sostegno del Killfile

 istruzioni?
Se non sbaglio gli indirizzi vengono salvati nel registro di stack, ed
immagino che questi indirizzi siano il posto dove riesiedono le
istruzioni
a metà in ram; quindi una volta passato l'interrupt viene recuperato 
l'indirizzo dal registro di stack e si continua ad eseguire l'istruzione
(per logica ne deduco quindi, che le istruzioni vengono stoppate e 
poi riavviate)
Ribadisco che potrebbero essere un mucchio di fesserie...che
qualcun'altro
mi dica la sua 
Ciao :-)
Claudio
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


A parte che esistono anche Iinterrupt chiamati dal software e quindi
non solo da dispositivi hardware e se la cosa non fosse gestita in
modo "semplice" la cpu sarebbe al 90% occupata nella gestione
di questi benedetti IRQ...
Comunque queste linee sono utilizzate da quasi tutte le schede di I/O
per segnalare alla cpu stessa che necessitano di attenzione.
La gestione delle periferiche tramite interrupt non è l'unica possibile, ma
risulta senza dubbio la più efficiente inquanto la cpu opera sulla
periferica solo quando è veramente necessario, dedicandosi ad altri
compiti nel tempo rimanente. L'unica altra strategia possibile, il polling
prevede l'interrogazione ciclica delle schede di I/O per determinare
se queste richiedono o meno di essere gestite; questa procedura però
provoca un notevole spreco di tempo da parte della cpu ed è
utilizzabile solo quando questa non è impegnata in altre istruzioni (cioè
praticamente mai ;).
Invece utilizzando gli IRQ quando una periferica necessita di
attenzione attiva una  delle linee di richiesta di interruzione a seguito
della
quale la cpu termina l'istruzione in corso, salva la condizione attuale
nello Stack (come giustamente a detto Claudio) e si accinge a eseguire
la routine definita per quella particolare linea di IRQ. Le istruzioni
di programma contenute in questa routine provvedono alla gestione
della periferica che ha richiesto attenzione e, al termine della procedura
ristabiliscono la condizione che era presente prima dell'interruzione; la
cpu quindi potrà riprendere l'esecuzione del programma principale
dal punto in cui si era interrotta senza apparenti rallentamenti grazie
alla memoria "transitoria" residente nello Stack.
Spero d'essere stato chiaro.
Ciao.

 Spero d'essere stato chiaro.
Fin qua ci sono anche io, ma la mia domanda era: tutte le istruzioni di
prefetch o quelle che stanno nelle pipelines, che fine fanno?
Queste sono istruzioni che stanno DENTRO alla CPU e non mi risulta vengano
salvate nello stack....
Sbaglio?

 ha scritto nel messaggio
news:NAGq8.114714$1S3.3...@twister1.libero.it...

La gestione degli IRQ avviene in un circuito autonomo e non intacca
il procedimento di elaborazione delle istruzioni nelle varie unità di
esecuzine della cpu (non importa che la pipeline sia lunga 5 o 20 stadi).
Infine ti ricordo che anche quando si preme un semplice tasto sulla tastiera
viene generato un Interrupt, quindi sai che casini se si dovesse svuotare
la pipeline ogni volta che ci sta un IRQ...
Saluti.

 la pipeline ogni volta che ci sta un IRQ...
Si ci avevo pensato.. è per questo che ho fatto la domanda :))
Mi stai dicendo che pipelines e istruzioni di prefetch rimangono inalterate
anche durante la gestione degli interrupt?
Scusa eh, ma allora quando si passa da un processo all'altro perchè scade il
quanto di tempo assegnato dal SO al processo, che succede? Pipelines
svuotate ecc ecc? Non mi pare il max dell'efficienza.....
Magari ti sembro "de coccio" ma non ti seguo proprio :)


|| Ti posso dire che oltre all'interrupt di tastiera anche lo stesso
orologio
interno del pc ha un proprio interrupt, tramite il quale scandisce il tempo
con la frequenza di circa 18 volte al secondo. Può sembrare che ben
18 interruzioni al secondo debbano rallentare in modo significativo la
cpu; ma per rendersi conto che non è così basta pensare che tra due
interruzioni successive nelle cpu odierne (cioè anche sin dal 286) vengono
eseguite comunque diverse centinaia di istruzioni, facendo in modo
praticamente di non comportare nessun impatto negativo sulle perstazioni
della cpu stessa.

 della cpu stessa.
Ok, ma ste benedette istruzioni di prefetch e quelle che stanno nelle
pipelines che fine fanno quando arriva una richiesta di interrupt alla CPU?
Mi sento stupido :(((
:P

Lorenz wrote:
  > La gestione degli IRQ avviene in un circuito autonomo e non intacca
  > il procedimento di elaborazione delle istruzioni nelle varie unità di
  > esecuzine della cpu (non importa che la pipeline sia lunga 5 o 20 stadi).
  > Infine ti ricordo che anche quando si preme un semplice tasto sulla tastiera
  > viene generato un Interrupt, quindi sai che casini se si dovesse svuotare
  > la pipeline ogni volta che ci sta un IRQ...
Vediamo di chiarire la cosa , la gestione di un IRQ (giusto il passaggio
dalla routine in corso alla routine di gestione interrupt) sulle cpu
tipo x86 attuali E' PESANTE, corrisponde *come minimo* ad un jump
"predetto male" quindi come minimo c'e' il flush della parte di pipeline
"a monte" e nel caso peggiore corrisponde ad un task switch
vero e proprio (dipende da come vengono gestiti dalla accoppiata
cpu+S.O.).
Inoltre quasi certamente la routine di gestione interrupt ed i dati
su cui opera non sono in cache (e gia solo questa e' una bella mazzata
visto la differenza di velocita tra cache sulla cpu e ram esterna).
E' per questi motivi che se si devono gestire periferiche
"veloci" gli interrupt vengono generati solo quando
i buffer gestiti in hardware superano una certa soglia
di riempimento/svuotamento o solo quando un trasferimento
in DMA ha termine in modo da ridurre la frequenza
degli irq a livelli ragionevoli.
Giusto per fornire alcuni riferimenti, la tastiera e' una
periferica *molto*  "lenta", al massimo genera irq 10..30
volte al secondo, pure l'irq di vertical  retrace e' lento
(60..100 volte al secondo), pure un vecchio 8088 a 4Mhz
riusciva a gestirli senza problemi (contemporaneamente agli irq delle
seriali, agli irq dei timer ed a quelli dell'intefaccia con l'hard disk).
Ora con gli attuali x86 il "peso" di un irq e' maggiore perche
ci sono molte piu cose da fare per gestirlo, ma fortunatamene
le prestazioni complessive sono cresciute a sufficienza da evitare
situazioni imbarazzanti.
L. Micheletto


Beh, sicuramente già dalle cpu della generazione P5 c'è stato un
bel passo avanti per quanto riguarda l'efficienza elaborativa nei
sistemi x86.
Ciao.

 istruzioni ad ogni interrupt?
Si esatto anzi nei sistemi Win2000 e XP dove devono essere gestite da
specifiche routine del kernal aumenta enormemente la latenza agli
interupt, non ti hanno mai detto che gli attuali PC non sono adatti per il
"real time" ?
Quindi se ci mettono del tempo a servire un interupt non lo nota nessuno,
a meno di qualche malcapitato che pensa di mettere un PC con un processore
potente (ma non troppo perche` di solito sono applicazioni che richiedono
all'hardware di funzionare 24h/24h) al centro di un sistema real-time per
accorgersi in seguito che un bel RISC da poche decine di Mhz e un kernel
real time era molto piu` adatto.
Comunque il "flush" della pipeline e` una cosa irrosia rispetto al peso
della gestione dell' interupt stesso  quindi AMD o Intel non fa molta
differenza sono gli OS che non sono adatti al real time , per applicazioni
normali gli interupt anche se avvengo a 100Hz sono irrisori rispetto alla
potenza attuale delle CPU, per sistemi realmente real-time si usano magari
CPU meno potenti ma sicuramente OS piu` adatti anche l'intel ha il suo
real time kernel ma si usano su processori embedded semmai con core 486 o
RISC, AMD aveva un embedded basato sul K6 non so se ora ne ha uno basato
sul K7 ma non credo.
Giovanni