Il est dit que les interruptions peuvent survenir à n'importe quel
moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº
du vecteur d'interruption. Donc c'est bien un thread en cours
d'exécution, celui qui contient l'instruction assembleur "INT xx", qui
provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions" ?
"Papouille" wrote in message news:4920517f$0$28418$
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions "software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du vecteur d'interruption. Donc c'est bien un thread en cours d'exécution, celui qui contient l'instruction assembleur "INT xx", qui provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions" ?
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
"Papouille" <Papouille@papouille.net> wrote in message
news:4920517f$0$28418$426a74cc@news.free.fr...
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel moment,
imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du
vecteur d'interruption. Donc c'est bien un thread en cours d'exécution,
celui qui contient l'instruction assembleur "INT xx", qui provoque
l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions"
?
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de
1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
"Papouille" wrote in message news:4920517f$0$28418$
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions "software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du vecteur d'interruption. Donc c'est bien un thread en cours d'exécution, celui qui contient l'instruction assembleur "INT xx", qui provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions" ?
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Papouille
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une interruption software) mais sur la raison pour laquelle on l'appelle "interruption" alors que son action se situe à un moment totalement prévisible, à la différence des interruptions hardware par exemple...
Merci et à bientôt
Papouille
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de
1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption
software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était
une interruption software) mais sur la raison pour laquelle on l'appelle
"interruption" alors que son action se situe à un moment totalement
prévisible, à la différence des interruptions hardware par exemple...
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une interruption software) mais sur la raison pour laquelle on l'appelle "interruption" alors que son action se situe à un moment totalement prévisible, à la différence des interruptions hardware par exemple...
Merci et à bientôt
Papouille
antoine
"Papouille" wrote in message news:492077da$0$29787$
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une interruption software) mais sur la raison pour laquelle on l'appelle "interruption"
"interruption", car l'exécution du code est bien interrompue, pour exécuter comme il est dit "the handler routine specified in the interrupt descriptor table entry"
"Papouille" <Papouille@papouille.net> wrote in message
news:492077da$0$29787$426a74cc@news.free.fr...
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT"
de 1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption
software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une
interruption software) mais sur la raison pour laquelle on l'appelle
"interruption"
"interruption", car l'exécution du code est bien interrompue, pour exécuter
comme il est dit "the handler routine specified in the interrupt descriptor
table entry"
"Papouille" wrote in message news:492077da$0$29787$
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de 1999 Des extraits : "http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Merci, mais ma question ne porte pas sur ce qu'est une interruption software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une interruption software) mais sur la raison pour laquelle on l'appelle "interruption"
"interruption", car l'exécution du code est bien interrompue, pour exécuter comme il est dit "the handler routine specified in the interrupt descriptor table entry"
Vincent Burel
"Papouille" wrote in message news:4920517f$0$28418$
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions "software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du vecteur d'interruption. Donc c'est bien un thread en cours d'exécution, celui qui contient l'instruction assembleur "INT xx", qui provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions"
Ben, je dirais que les interruptions software sont le fait du logiciel ou viennent directement du processor. (un timer, le scheduler qui distribue la resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les interruptions hardware sont le fait d'élément extérieur au processeur (arrivé de données sur un port, réponse de controleurs etc... ).
VB
"Papouille" <Papouille@papouille.net> wrote in message
news:4920517f$0$28418$426a74cc@news.free.fr...
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel
moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº
du vecteur d'interruption. Donc c'est bien un thread en cours
d'exécution, celui qui contient l'instruction assembleur "INT xx", qui
provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions"
Ben, je dirais que les interruptions software sont le fait du logiciel ou
viennent directement du processor. (un timer, le scheduler qui distribue la
resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les
interruptions hardware sont le fait d'élément extérieur au processeur
(arrivé de données sur un port, réponse de controleurs etc... ).
"Papouille" wrote in message news:4920517f$0$28418$
Bonjour,
Il est dit que les interruptions peuvent survenir à n'importe quel moment, imprévisible, au cours de l'exécution d'un thread.
Dans les interruptions, on distingue les interruptions hardware et les interruptions software.
je ne comprends pas en quoi l'on peut dire que les interruptions "software" peuvent survenir à n'importe quel moment.
En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du vecteur d'interruption. Donc c'est bien un thread en cours d'exécution, celui qui contient l'instruction assembleur "INT xx", qui provoque l'interruption software.
Il n'y a rien d'impévisible, là...
En quoi les interruptions "software" font-elles partie des "interruptions"
Ben, je dirais que les interruptions software sont le fait du logiciel ou viennent directement du processor. (un timer, le scheduler qui distribue la resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les interruptions hardware sont le fait d'élément extérieur au processeur (arrivé de données sur un port, réponse de controleurs etc... ).
VB
Papouille
antoine a écrit :
"interruption", car l'exécution du code est bien interrompue, pour exécuter comme il est dit "the handler routine specified in the interrupt descriptor table entry"
Oui, le code est interrompu. Mais les exceptions interrompent aussi le code, et pourtant ce ne sont pas des interruptions.
Les interruptions sont imprévisibles.
En quoi les interruptions *software* le sont ?
antoine a écrit :
"interruption", car l'exécution du code est bien interrompue, pour exécuter
comme il est dit "the handler routine specified in the interrupt descriptor
table entry"
Oui, le code est interrompu. Mais les exceptions interrompent aussi le
code, et pourtant ce ne sont pas des interruptions.
"interruption", car l'exécution du code est bien interrompue, pour exécuter comme il est dit "the handler routine specified in the interrupt descriptor table entry"
Oui, le code est interrompu. Mais les exceptions interrompent aussi le code, et pourtant ce ne sont pas des interruptions.
Les interruptions sont imprévisibles.
En quoi les interruptions *software* le sont ?
Papouille
> Ben, je dirais que les interruptions software sont le fait du logiciel ou viennent directement du processor. (un timer, le scheduler qui distribue la resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les interruptions hardware sont le fait d'élément extérieur au processeur (arrivé de données sur un port, réponse de controleurs etc... ).
VB
Oui, mais les exceptions (division par zéro, page default) ne sont pas des interruptions, dans la mesure où en répétant le même code dans les même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware - qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit de soft (de code assembleur) et non pas de hardware ?
> Ben, je dirais que les interruptions software sont le fait du logiciel ou
viennent directement du processor. (un timer, le scheduler qui distribue la
resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les
interruptions hardware sont le fait d'élément extérieur au processeur
(arrivé de données sur un port, réponse de controleurs etc... ).
VB
Oui, mais les exceptions (division par zéro, page default) ne sont pas
des interruptions, dans la mesure où en répétant le même code dans les
même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware -
qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit
de soft (de code assembleur) et non pas de hardware ?
> Ben, je dirais que les interruptions software sont le fait du logiciel ou viennent directement du processor. (un timer, le scheduler qui distribue la resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les interruptions hardware sont le fait d'élément extérieur au processeur (arrivé de données sur un port, réponse de controleurs etc... ).
VB
Oui, mais les exceptions (division par zéro, page default) ne sont pas des interruptions, dans la mesure où en répétant le même code dans les même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware - qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit de soft (de code assembleur) et non pas de hardware ?
Vincent Burel
"Papouille" wrote in message news:4921bb9c$0$7770$
> Ben, je dirais que les interruptions software sont le fait du logiciel
ou
> viennent directement du processor. (un timer, le scheduler qui distribue
la
> resource CPU aux thread, une division par zéro, le mode debug etc... ) .
Les
> interruptions hardware sont le fait d'élément extérieur au processeur > (arrivé de données sur un port, réponse de controleurs etc... ). > > VB > >
Oui, mais les exceptions (division par zéro, page default) ne sont pas des interruptions, dans la mesure où en répétant le même code dans les même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware - qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit de soft (de code assembleur) et non pas de hardware ?
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre le cours normal des choses. La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne change pas la nature du phénomène : l'interruption du cours du programme principale. Après il faut entendre ce qu'on entend par "prévisible" , quand on attend une interruption d'un controler disk en réponse à une requète, on sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire facilement, de manière déterministe si quand un zéro va apparaitre sur un diviseur.
VB
"Papouille" <Papouille@papouille.net> wrote in message
news:4921bb9c$0$7770$426a74cc@news.free.fr...
> Ben, je dirais que les interruptions software sont le fait du logiciel
ou
> viennent directement du processor. (un timer, le scheduler qui distribue
la
> resource CPU aux thread, une division par zéro, le mode debug etc... ) .
Les
> interruptions hardware sont le fait d'élément extérieur au processeur
> (arrivé de données sur un port, réponse de controleurs etc... ).
>
> VB
>
>
Oui, mais les exceptions (division par zéro, page default) ne sont pas
des interruptions, dans la mesure où en répétant le même code dans les
même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware -
qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit
de soft (de code assembleur) et non pas de hardware ?
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre
le cours normal des choses.
La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne
change pas la nature du phénomène : l'interruption du cours du programme
principale. Après il faut entendre ce qu'on entend par "prévisible" , quand
on attend une interruption d'un controler disk en réponse à une requète, on
sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est
pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire
facilement, de manière déterministe si quand un zéro va apparaitre sur un
diviseur.
"Papouille" wrote in message news:4921bb9c$0$7770$
> Ben, je dirais que les interruptions software sont le fait du logiciel
ou
> viennent directement du processor. (un timer, le scheduler qui distribue
la
> resource CPU aux thread, une division par zéro, le mode debug etc... ) .
Les
> interruptions hardware sont le fait d'élément extérieur au processeur > (arrivé de données sur un port, réponse de controleurs etc... ). > > VB > >
Oui, mais les exceptions (division par zéro, page default) ne sont pas des interruptions, dans la mesure où en répétant le même code dans les même conditions, l'exception se répète aussi.
Ce qui n'est pas le cas des interruptions - software comme hardware - qui sont imprévisibles.
En quoi une interruption software est-elle imprévisible puisqu'il s'agit de soft (de code assembleur) et non pas de hardware ?
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre le cours normal des choses. La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne change pas la nature du phénomène : l'interruption du cours du programme principale. Après il faut entendre ce qu'on entend par "prévisible" , quand on attend une interruption d'un controler disk en réponse à une requète, on sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire facilement, de manière déterministe si quand un zéro va apparaitre sur un diviseur.
VB
Papouille
Vincent Burel a écrit :
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre le cours normal des choses. La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne change pas la nature du phénomène : l'interruption du cours du programme principale. Après il faut entendre ce qu'on entend par "prévisible" , quand on attend une interruption d'un controler disk en réponse à une requète, on sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire facilement, de manière déterministe si quand un zéro va apparaitre sur un diviseur.
VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
La prévisibilité ou non EST la définition de l'interruption versus l'exception.
Les interruptions sont dites asynchrones, les exceptions sont synchrones, et ces dernières sont provoquées par l'exécution d'une instruction assembleur (page fault, division par zéro..).
Ce qui est prévisible n'est pas une interruption, mais une exception.
la division par zéro n'est pas une interruption, mais une exception.
La "page fault" n'est pas une interruption,mais une exception.
Ces deux mécanismes (interruptions et exceptions) se subdivisent d'ailleurs :
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
- Les exceptions se subdivisent en "faults", "Traps" et "aborts".
Vincent Burel a écrit :
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre
le cours normal des choses.
La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne
change pas la nature du phénomène : l'interruption du cours du programme
principale. Après il faut entendre ce qu'on entend par "prévisible" , quand
on attend une interruption d'un controler disk en réponse à une requète, on
sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est
pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire
facilement, de manière déterministe si quand un zéro va apparaitre sur un
diviseur.
VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
La prévisibilité ou non EST la définition de l'interruption versus
l'exception.
Les interruptions sont dites asynchrones, les exceptions sont
synchrones, et ces dernières sont provoquées par l'exécution d'une
instruction assembleur (page fault, division par zéro..).
Ce qui est prévisible n'est pas une interruption, mais une exception.
la division par zéro n'est pas une interruption, mais une exception.
La "page fault" n'est pas une interruption,mais une exception.
Ces deux mécanismes (interruptions et exceptions) se subdivisent
d'ailleurs :
- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".
- Les exceptions se subdivisent en "faults", "Traps" et "aborts".
Une interruption, comme sont nom l'indique est qqc qui va venir interrompre le cours normal des choses. La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne change pas la nature du phénomène : l'interruption du cours du programme principale. Après il faut entendre ce qu'on entend par "prévisible" , quand on attend une interruption d'un controler disk en réponse à une requète, on sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire facilement, de manière déterministe si quand un zéro va apparaitre sur un diviseur.
VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
La prévisibilité ou non EST la définition de l'interruption versus l'exception.
Les interruptions sont dites asynchrones, les exceptions sont synchrones, et ces dernières sont provoquées par l'exécution d'une instruction assembleur (page fault, division par zéro..).
Ce qui est prévisible n'est pas une interruption, mais une exception.
la division par zéro n'est pas une interruption, mais une exception.
La "page fault" n'est pas une interruption,mais une exception.
Ces deux mécanismes (interruptions et exceptions) se subdivisent d'ailleurs :
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
- Les exceptions se subdivisent en "faults", "Traps" et "aborts".
Vincent Burel
"Papouille" wrote in message news:49230d2d$0$13865$
Vincent Burel a écrit : > > Une interruption, comme sont nom l'indique est qqc qui va venir
interrompre
> le cours normal des choses. > La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption
ne
> change pas la nature du phénomène : l'interruption du cours du programme > principale. Après il faut entendre ce qu'on entend par "prévisible" ,
quand
> on attend une interruption d'un controler disk en réponse à une requète,
on
> sait qu'il va y avoir une interruption, mais on ne sait pas quand.
C'est
> pareil pour la division par zero, y'a des calcul où l'on ne sait pas
dire
> facilement, de manière déterministe si quand un zéro va apparaitre sur
un
> diviseur. > > VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
oui, j'ai du mal à vous suivre.
Ce qui est prévisible n'est pas une interruption, mais une exception.
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à mettre en place ce mécanisme.
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question. peut etre qqn d'autre... VB
"Papouille" <Papouille@papouille.net> wrote in message
news:49230d2d$0$13865$426a74cc@news.free.fr...
Vincent Burel a écrit :
>
> Une interruption, comme sont nom l'indique est qqc qui va venir
interrompre
> le cours normal des choses.
> La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption
ne
> change pas la nature du phénomène : l'interruption du cours du programme
> principale. Après il faut entendre ce qu'on entend par "prévisible" ,
quand
> on attend une interruption d'un controler disk en réponse à une requète,
on
> sait qu'il va y avoir une interruption, mais on ne sait pas quand.
C'est
> pareil pour la division par zero, y'a des calcul où l'on ne sait pas
dire
> facilement, de manière déterministe si quand un zéro va apparaitre sur
un
> diviseur.
>
> VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
oui, j'ai du mal à vous suivre.
Ce qui est prévisible n'est pas une interruption, mais une exception.
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à
mettre en place ce mécanisme.
- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question.
peut etre qqn d'autre...
VB
"Papouille" wrote in message news:49230d2d$0$13865$
Vincent Burel a écrit : > > Une interruption, comme sont nom l'indique est qqc qui va venir
interrompre
> le cours normal des choses. > La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption
ne
> change pas la nature du phénomène : l'interruption du cours du programme > principale. Après il faut entendre ce qu'on entend par "prévisible" ,
quand
> on attend une interruption d'un controler disk en réponse à une requète,
on
> sait qu'il va y avoir une interruption, mais on ne sait pas quand.
C'est
> pareil pour la division par zero, y'a des calcul où l'on ne sait pas
dire
> facilement, de manière déterministe si quand un zéro va apparaitre sur
un
> diviseur. > > VB
Oui, mais non, nous ne sommes pas sur la même longueur d'onde...
oui, j'ai du mal à vous suivre.
Ce qui est prévisible n'est pas une interruption, mais une exception.
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à mettre en place ce mécanisme.
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question. peut etre qqn d'autre... VB
Papouille
Vincent Burel a écrit :
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à mettre en place ce mécanisme.
En fait, si vous chargez un registre du microprocessuer avec la valeur 0 puis utilisez une instruction en langage machine faisant la division d'un nombre avec le contenu de ce registre, vous provoquez une exception. Si vous exécutez à nouveau le même programme dans les mêmes conditions (mêmes paramètres d'entrée du programme) vous provoquerez à nouveau l'exception.
Cette exception est traitée par une routine d'interruption, puis le programme reprend là où l'exception a été générée. C'est-à-dire qu'il re-exécute la même instruction. Donc il y a une ressemblance avec les interruptions "ordinaires" dans le sens où effectivement intervient une routine d'interruption, mais une différence avec une interruption ordinaire dans le sens où : 1/ En re-exécutant deux fois le même programme avec les mêmes paramètres d'entrée, l'exception sera à nouveau provoquée, à la différence d'une "interruption" qui peut être provoquée à tout moment entre n'importe quelle instruction, quels que soeint les paramètres d'entrée du programme 2/ Une exception, après traitement, reprend l'exécution du programme en re-exécutant l'instruction l'ayant provoquée. Une interruption, elle, provoque le retour du programme sur l'instruction *suivante* de celle ayant été interrompue.
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question. peut etre qqn d'autre... VB
Ce n'est pas simple : pour moi, les interruptions software sont prévisibles. Comme les exceptions... alors pourquoi les appeler "interruptions" ? j'ai deux possibilités, mqis qui ne me convainquent pas : 1/ retour sur le programme interrompu : l'interruption software fait reprendre l'exécution du programme sur l'instruction suivant celle ayant été interrompue. Comme les interruptions software. Mais je ne retrouve pas ici la définition de l'interruption au sens "d'évènement imprévisible". 2/ Les interruptions software, si elles sont contenues dans un thread du kernel, peuvent imposer l'interruption d'un user-thread (préemption du user-thread par le kernel) dans la mesure où elles s'exécutent à une priorité (IRQL) plus élevée que celle du user-thread en cours d'exécution. Le user thread s'est interrompu de manière "imprévisble". On retrouve l'imprévisibilité de l'interruption du point de vue du user-thread. Par contre ce n'était pas imprévisible du point de vue du kernel-thread.... Mais cela me laisse perplexe... je ne suis pas convaincu...
Vincent Burel a écrit :
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à
mettre en place ce mécanisme.
En fait, si vous chargez un registre du microprocessuer avec la valeur 0
puis utilisez une instruction en langage machine faisant la division
d'un nombre avec le contenu de ce registre, vous provoquez une
exception. Si vous exécutez à nouveau le même programme dans les mêmes
conditions (mêmes paramètres d'entrée du programme) vous provoquerez à
nouveau l'exception.
Cette exception est traitée par une routine d'interruption, puis le
programme reprend là où l'exception a été générée. C'est-à-dire qu'il
re-exécute la même instruction. Donc il y a une ressemblance avec les
interruptions "ordinaires" dans le sens où effectivement intervient une
routine d'interruption, mais une différence avec une interruption
ordinaire dans le sens où :
1/ En re-exécutant deux fois le même programme avec les mêmes paramètres
d'entrée, l'exception sera à nouveau provoquée, à la différence d'une
"interruption" qui peut être provoquée à tout moment entre n'importe
quelle instruction, quels que soeint les paramètres d'entrée du programme
2/ Une exception, après traitement, reprend l'exécution du programme en
re-exécutant l'instruction l'ayant provoquée. Une interruption, elle,
provoque le retour du programme sur l'instruction *suivante* de celle
ayant été interrompue.
- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question.
peut etre qqn d'autre...
VB
Ce n'est pas simple : pour moi, les interruptions software sont
prévisibles. Comme les exceptions... alors pourquoi les appeler
"interruptions" ? j'ai deux possibilités, mqis qui ne me convainquent pas :
1/ retour sur le programme interrompu : l'interruption software fait
reprendre l'exécution du programme sur l'instruction suivant celle ayant
été interrompue. Comme les interruptions software. Mais je ne retrouve
pas ici la définition de l'interruption au sens "d'évènement imprévisible".
2/ Les interruptions software, si elles sont contenues dans un thread du
kernel, peuvent imposer l'interruption d'un user-thread (préemption du
user-thread par le kernel) dans la mesure où elles s'exécutent à une
priorité (IRQL) plus élevée que celle du user-thread en cours
d'exécution. Le user thread s'est interrompu de manière "imprévisble".
On retrouve l'imprévisibilité de l'interruption du point de vue du
user-thread. Par contre ce n'était pas imprévisible du point de vue du
kernel-thread.... Mais cela me laisse perplexe... je ne suis pas
convaincu...
une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à mettre en place ce mécanisme.
En fait, si vous chargez un registre du microprocessuer avec la valeur 0 puis utilisez une instruction en langage machine faisant la division d'un nombre avec le contenu de ce registre, vous provoquez une exception. Si vous exécutez à nouveau le même programme dans les mêmes conditions (mêmes paramètres d'entrée du programme) vous provoquerez à nouveau l'exception.
Cette exception est traitée par une routine d'interruption, puis le programme reprend là où l'exception a été générée. C'est-à-dire qu'il re-exécute la même instruction. Donc il y a une ressemblance avec les interruptions "ordinaires" dans le sens où effectivement intervient une routine d'interruption, mais une différence avec une interruption ordinaire dans le sens où : 1/ En re-exécutant deux fois le même programme avec les mêmes paramètres d'entrée, l'exception sera à nouveau provoquée, à la différence d'une "interruption" qui peut être provoquée à tout moment entre n'importe quelle instruction, quels que soeint les paramètres d'entrée du programme 2/ Une exception, après traitement, reprend l'exécution du programme en re-exécutant l'instruction l'ayant provoquée. Une interruption, elle, provoque le retour du programme sur l'instruction *suivante* de celle ayant été interrompue.
- Les interruptions se subdivisent en "Interruptions Hardware" et "interruptions software".
L'exception provoque généralement une interruption...
Bref, je ne comprend plus votre question. peut etre qqn d'autre... VB
Ce n'est pas simple : pour moi, les interruptions software sont prévisibles. Comme les exceptions... alors pourquoi les appeler "interruptions" ? j'ai deux possibilités, mqis qui ne me convainquent pas : 1/ retour sur le programme interrompu : l'interruption software fait reprendre l'exécution du programme sur l'instruction suivant celle ayant été interrompue. Comme les interruptions software. Mais je ne retrouve pas ici la définition de l'interruption au sens "d'évènement imprévisible". 2/ Les interruptions software, si elles sont contenues dans un thread du kernel, peuvent imposer l'interruption d'un user-thread (préemption du user-thread par le kernel) dans la mesure où elles s'exécutent à une priorité (IRQL) plus élevée que celle du user-thread en cours d'exécution. Le user thread s'est interrompu de manière "imprévisble". On retrouve l'imprévisibilité de l'interruption du point de vue du user-thread. Par contre ce n'était pas imprévisible du point de vue du kernel-thread.... Mais cela me laisse perplexe... je ne suis pas convaincu...
