suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Michel__D a écrit :
>> suivant celle ayant été interrompue).
>
> Et bien la boucle est bouclée, on dirait.
>
> PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Michel__D a écrit :
>> suivant celle ayant été interrompue).
>
> Et bien la boucle est bouclée, on dirait.
>
> PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Michel__D a écrit :
>> suivant celle ayant été interrompue).
>
> Et bien la boucle est bouclée, on dirait.
>
> PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
"Papouille" wrote in message
news:49270c41$0$18206$Michel__D a écrit :suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 , procedure
calls, Interrupts and Exceptions).
VB
"Papouille" <Papouille@papouille.net> wrote in message
news:49270c41$0$18206$426a34cc@news.free.fr...
Michel__D a écrit :
suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 , procedure
calls, Interrupts and Exceptions).
VB
"Papouille" wrote in message
news:49270c41$0$18206$Michel__D a écrit :suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 , procedure
calls, Interrupts and Exceptions).
VB
Vincent Burel a écrit :"Papouille" wrote in message
news:49270c41$0$18206$Michel__D a écrit :suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc
Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 ,
procedure
calls, Interrupts and Exceptions).
VB
J'avais déjà lu ces chapitres avant de poser la question sur ce forum.
Justement chapitre 6.4 de ce livre il est écrit "An interrupt is an
*asynchronous* event that is typically triggered by an I/O device."
Cependant, "typically" ne signifie pas que "exclusivement". La preuve
est que les interruptions software sont classées dans les interruptions.
Il est dit juste après :
An "exception is a *synchronous* event that is generated when the
processor detects one or more predefined conditions while executing an
instruction."
Ce que j'ai écrit dans ce fil provient de ce livre au niveau des
classements des interruptions et des exceptions. Je n'ai rien inventé..
Ce que je crois, c'est qu'il me manque un concept que j'ai du mal à
identifier pour bien comprendre la raison pour laquelle une interruption
software est considérée comme "asynchronous".
Vincent Burel a écrit :
"Papouille" <Papouille@papouille.net> wrote in message
news:49270c41$0$18206$426a34cc@news.free.fr...
Michel__D a écrit :
suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc
Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 ,
procedure
calls, Interrupts and Exceptions).
VB
J'avais déjà lu ces chapitres avant de poser la question sur ce forum.
Justement chapitre 6.4 de ce livre il est écrit "An interrupt is an
*asynchronous* event that is typically triggered by an I/O device."
Cependant, "typically" ne signifie pas que "exclusivement". La preuve
est que les interruptions software sont classées dans les interruptions.
Il est dit juste après :
An "exception is a *synchronous* event that is generated when the
processor detects one or more predefined conditions while executing an
instruction."
Ce que j'ai écrit dans ce fil provient de ce livre au niveau des
classements des interruptions et des exceptions. Je n'ai rien inventé..
Ce que je crois, c'est qu'il me manque un concept que j'ai du mal à
identifier pour bien comprendre la raison pour laquelle une interruption
software est considérée comme "asynchronous".
Vincent Burel a écrit :"Papouille" wrote in message
news:49270c41$0$18206$Michel__D a écrit :suivant celle ayant été interrompue).
Et bien la boucle est bouclée, on dirait.
PS:Il ne faut pas forcément croire tout ce que les livres racontent.
Oui, mais cette explication ne me satisfait pas : le bouquin en question
est LA référence de tous ceux qui veulent comprendre comment Windows
fonctionne ("Microsoft Windows Internals" - Microsoft Press - Mark E.
Russinovich et David A. Solomon) et est cité par les plus grands auteurs
de livres sur les operating systems (comme grand auteur sur les
système d'exploitation, je cite Tanenbaum, qui informe son lecteur que
ce livre est largement au dessus du niveau de tous les autres sur la
question).
Interruption et Exception, avant d'être géré par l'OS , sont gérés par le
processeur, peut etre que vous devriez plutot jeter un oeil sur la Doc
Intel
IA32 par exemple (25366514_V1_Basic_Architecture.pdf chapter 6 ,
procedure
calls, Interrupts and Exceptions).
VB
J'avais déjà lu ces chapitres avant de poser la question sur ce forum.
Justement chapitre 6.4 de ce livre il est écrit "An interrupt is an
*asynchronous* event that is typically triggered by an I/O device."
Cependant, "typically" ne signifie pas que "exclusivement". La preuve
est que les interruptions software sont classées dans les interruptions.
Il est dit juste après :
An "exception is a *synchronous* event that is generated when the
processor detects one or more predefined conditions while executing an
instruction."
Ce que j'ai écrit dans ce fil provient de ce livre au niveau des
classements des interruptions et des exceptions. Je n'ai rien inventé..
Ce que je crois, c'est qu'il me manque un concept que j'ai du mal à
identifier pour bien comprendre la raison pour laquelle une interruption
software est considérée comme "asynchronous".
Les interruptions sont masquables mais pas les exceptions.
Les interruptions sont masquables mais pas les exceptions.
Les interruptions sont masquables mais pas les exceptions.
Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Papouille a écrit :Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Il y a aussi :
http://www.irisa.fr/caps/PROJECTS/TechnologicalSurvey/micro/PI-1024-html/section2_7_7.html
où est écrit :
"Les exceptions générées logiciellement (souvent appelées <<interruption
logicielle>>). Ces interruptions sont générées par l'instruction INT et
sont traitées par le microprocesseur comme des exceptions"
Comme quoi, les interruptions *logicielles* font partie des exceptions.
Et voilà, c'est fini : les auteurs parlant des interruptions omettent de
dire que leurs définition ne s'applique pas aux interruptions
logicielles....
Au lecteur de faire le travail de réflexion !
Papouille a écrit :
Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Il y a aussi :
http://www.irisa.fr/caps/PROJECTS/TechnologicalSurvey/micro/PI-1024-html/section2_7_7.html
où est écrit :
"Les exceptions générées logiciellement (souvent appelées <<interruption
logicielle>>). Ces interruptions sont générées par l'instruction INT et
sont traitées par le microprocesseur comme des exceptions"
Comme quoi, les interruptions *logicielles* font partie des exceptions.
Et voilà, c'est fini : les auteurs parlant des interruptions omettent de
dire que leurs définition ne s'applique pas aux interruptions
logicielles....
Au lecteur de faire le travail de réflexion !
Papouille a écrit :Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
J'ai vu aussi un cours de l'ULB sur internet qui classe les
interruptions logicielles comme étant des "exceptions programmées"...
http://stic.ulb.ac.be/Members/pfrancq/slides/info-h-406/InterruptionsExceptions.pdf
Il y a aussi :
http://www.irisa.fr/caps/PROJECTS/TechnologicalSurvey/micro/PI-1024-html/section2_7_7.html
où est écrit :
"Les exceptions générées logiciellement (souvent appelées <<interruption
logicielle>>). Ces interruptions sont générées par l'instruction INT et
sont traitées par le microprocesseur comme des exceptions"
Comme quoi, les interruptions *logicielles* font partie des exceptions.
Et voilà, c'est fini : les auteurs parlant des interruptions omettent de
dire que leurs définition ne s'applique pas aux interruptions
logicielles....
Au lecteur de faire le travail de réflexion !
Michel__D a écrit :
>
> Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
Michel__D a écrit :
>
> Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
Michel__D a écrit :
>
> Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
"Papouille" wrote in message
news:492871f8$0$19545$Michel__D a écrit :Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
si, les exceptions sont masquables. quant au interruptions logicielle, elles
sont forcément masquable car remplaçables ou détournables.
je pense qu'une partie de la confusion de ce thread vient du fait que le
mécanisme (logiciel) d'interruption est en premier lieu une méthode
"prioritaire" d'appel de sous routine (leur caractère prévisible ou pas ,
synchrone ou pas, n'affecte en rien leur nature : interruption). A l'époque
du DOS, on entendait par interruption logicielle, les fonctions systèmes du
DOS ou du BIOS.
VB
"Papouille" <Papouille@papouille.net> wrote in message
news:492871f8$0$19545$426a74cc@news.free.fr...
Michel__D a écrit :
Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
si, les exceptions sont masquables. quant au interruptions logicielle, elles
sont forcément masquable car remplaçables ou détournables.
je pense qu'une partie de la confusion de ce thread vient du fait que le
mécanisme (logiciel) d'interruption est en premier lieu une méthode
"prioritaire" d'appel de sous routine (leur caractère prévisible ou pas ,
synchrone ou pas, n'affecte en rien leur nature : interruption). A l'époque
du DOS, on entendait par interruption logicielle, les fonctions systèmes du
DOS ou du BIOS.
VB
"Papouille" wrote in message
news:492871f8$0$19545$Michel__D a écrit :Les interruptions sont masquables mais pas les exceptions.
Je ne sais pas si une interruption logicielle est masquable...
si, les exceptions sont masquables. quant au interruptions logicielle, elles
sont forcément masquable car remplaçables ou détournables.
je pense qu'une partie de la confusion de ce thread vient du fait que le
mécanisme (logiciel) d'interruption est en premier lieu une méthode
"prioritaire" d'appel de sous routine (leur caractère prévisible ou pas ,
synchrone ou pas, n'affecte en rien leur nature : interruption). A l'époque
du DOS, on entendait par interruption logicielle, les fonctions systèmes du
DOS ou du BIOS.
VB
Vincent Burel a écrit :
> "Papouille" wrote in message
> news:492871f8$0$19545$
>> Michel__D a écrit :
>>> Les interruptions sont masquables mais pas les exceptions.
>> Je ne sais pas si une interruption logicielle est masquable...
>
> si, les exceptions sont masquables. quant au interruptions logicielle,
> sont forcément masquable car remplaçables ou détournables.
>
> je pense qu'une partie de la confusion de ce thread vient du fait que le
> mécanisme (logiciel) d'interruption est en premier lieu une méthode
> "prioritaire" d'appel de sous routine (leur caractère prévisible ou pas
> synchrone ou pas, n'affecte en rien leur nature : interruption). A
> du DOS, on entendait par interruption logicielle, les fonctions systèmes
> DOS ou du BIOS.
>
> VB
>
>
>
Par masquable, j'entendais masquable par registre au niveau du CPU ou de
l'APIC (ce qui n'est possible que pour les interruptions hardware), et
non par déroutement logiciel.
Cela dit, la confusion de ce thread provient exclusivement du mode de
déclenchement *asynchrone* que l'on prête aux interruptions *par
définition*, ce qui en définitive n'est pas le cas car les interruptions
logicielles sont synchrones (déclenchées par des instructions du
microprocesseur) et non pas asynchrones.
Les urls que j'ai indiquées établissent clairement la nature synchrone
du traitement des interruptions logicielles, ce qui contredit les
auteurs qui écrivent que les interruptions sont des mécanismes
asynchrones qui les différencie des exceptions, synchrones. Ces auteurs
oublient seulement que leur définition ne s'applique pas aux
interruptions logicielles.
Cela dit, les interruptions logicielles seront certainement appelées
*interruption* au lieu d' *exception* pour des raisons purement
Les appels système DOS sont équivalents aux appels système Windows : ils
se déclenchent sur interruption logicielle.
Vincent Burel a écrit :
> "Papouille" <Papouille@papouille.net> wrote in message
> news:492871f8$0$19545$426a74cc@news.free.fr...
>> Michel__D a écrit :
>>> Les interruptions sont masquables mais pas les exceptions.
>> Je ne sais pas si une interruption logicielle est masquable...
>
> si, les exceptions sont masquables. quant au interruptions logicielle,
> sont forcément masquable car remplaçables ou détournables.
>
> je pense qu'une partie de la confusion de ce thread vient du fait que le
> mécanisme (logiciel) d'interruption est en premier lieu une méthode
> "prioritaire" d'appel de sous routine (leur caractère prévisible ou pas
> synchrone ou pas, n'affecte en rien leur nature : interruption). A
> du DOS, on entendait par interruption logicielle, les fonctions systèmes
> DOS ou du BIOS.
>
> VB
>
>
>
Par masquable, j'entendais masquable par registre au niveau du CPU ou de
l'APIC (ce qui n'est possible que pour les interruptions hardware), et
non par déroutement logiciel.
Cela dit, la confusion de ce thread provient exclusivement du mode de
déclenchement *asynchrone* que l'on prête aux interruptions *par
définition*, ce qui en définitive n'est pas le cas car les interruptions
logicielles sont synchrones (déclenchées par des instructions du
microprocesseur) et non pas asynchrones.
Les urls que j'ai indiquées établissent clairement la nature synchrone
du traitement des interruptions logicielles, ce qui contredit les
auteurs qui écrivent que les interruptions sont des mécanismes
asynchrones qui les différencie des exceptions, synchrones. Ces auteurs
oublient seulement que leur définition ne s'applique pas aux
interruptions logicielles.
Cela dit, les interruptions logicielles seront certainement appelées
*interruption* au lieu d' *exception* pour des raisons purement
Les appels système DOS sont équivalents aux appels système Windows : ils
se déclenchent sur interruption logicielle.
Vincent Burel a écrit :
> "Papouille" wrote in message
> news:492871f8$0$19545$
>> Michel__D a écrit :
>>> Les interruptions sont masquables mais pas les exceptions.
>> Je ne sais pas si une interruption logicielle est masquable...
>
> si, les exceptions sont masquables. quant au interruptions logicielle,
> sont forcément masquable car remplaçables ou détournables.
>
> je pense qu'une partie de la confusion de ce thread vient du fait que le
> mécanisme (logiciel) d'interruption est en premier lieu une méthode
> "prioritaire" d'appel de sous routine (leur caractère prévisible ou pas
> synchrone ou pas, n'affecte en rien leur nature : interruption). A
> du DOS, on entendait par interruption logicielle, les fonctions systèmes
> DOS ou du BIOS.
>
> VB
>
>
>
Par masquable, j'entendais masquable par registre au niveau du CPU ou de
l'APIC (ce qui n'est possible que pour les interruptions hardware), et
non par déroutement logiciel.
Cela dit, la confusion de ce thread provient exclusivement du mode de
déclenchement *asynchrone* que l'on prête aux interruptions *par
définition*, ce qui en définitive n'est pas le cas car les interruptions
logicielles sont synchrones (déclenchées par des instructions du
microprocesseur) et non pas asynchrones.
Les urls que j'ai indiquées établissent clairement la nature synchrone
du traitement des interruptions logicielles, ce qui contredit les
auteurs qui écrivent que les interruptions sont des mécanismes
asynchrones qui les différencie des exceptions, synchrones. Ces auteurs
oublient seulement que leur définition ne s'applique pas aux
interruptions logicielles.
Cela dit, les interruptions logicielles seront certainement appelées
*interruption* au lieu d' *exception* pour des raisons purement
Les appels système DOS sont équivalents aux appels système Windows : ils
se déclenchent sur interruption logicielle.