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" ?
Merci Vincent pour l'ensemble de vos contributions et pour bien voulu avoir passé du temps sur ces reflexions.
Bien cordialement
Papouille
Vincent Burel
De rien, J'aurais aimé savoir si tout cela avait un but précis, vous faites un bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au cours du temps (par les uns et les autres), font apparaitre des contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ, y'avait une simple notice technique, pas forcément en accord avec un modèle théorique parfait, mais répondant à des problèmes généralement trés terre à terre.
VB
"Papouille" wrote in message news:4929a59b$0$9900$
>
Merci Vincent pour l'ensemble de vos contributions et pour bien voulu avoir passé du temps sur ces reflexions.
Bien cordialement
Papouille
De rien,
J'aurais aimé savoir si tout cela avait un but précis, vous faites un
bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au
cours du temps (par les uns et les autres), font apparaitre des
contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ,
y'avait une simple notice technique, pas forcément en accord avec un modèle
théorique parfait, mais répondant à des problèmes généralement trés terre à
terre.
VB
"Papouille" <Papouille@papouille.net> wrote in message
news:4929a59b$0$9900$426a74cc@news.free.fr...
>
Merci Vincent pour l'ensemble de vos contributions et pour bien voulu
avoir passé du temps sur ces reflexions.
De rien, J'aurais aimé savoir si tout cela avait un but précis, vous faites un bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au cours du temps (par les uns et les autres), font apparaitre des contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ, y'avait une simple notice technique, pas forcément en accord avec un modèle théorique parfait, mais répondant à des problèmes généralement trés terre à terre.
VB
"Papouille" wrote in message news:4929a59b$0$9900$
>
Merci Vincent pour l'ensemble de vos contributions et pour bien voulu avoir passé du temps sur ces reflexions.
Bien cordialement
Papouille
Papouille
Vincent Burel a écrit :
De rien, J'aurais aimé savoir si tout cela avait un but précis, vous faites un bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au cours du temps (par les uns et les autres), font apparaitre des contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ, y'avait une simple notice technique, pas forcément en accord avec un modèle théorique parfait, mais répondant à des problèmes généralement trés terre à terre.
Non, pas de but précis, juste le désir de comprendre ce que je lis.
J'ai développé des systèmes d'exploitation sur des cartes à puce, et suis curieux de comprendre comment d'autres systèmes d'exploitation peuvent fonctionner.
D'où mon étude actuelle sur le système d'exploitation Windows.
Bien cordialement
Papouille
Vincent Burel a écrit :
De rien,
J'aurais aimé savoir si tout cela avait un but précis, vous faites un
bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au
cours du temps (par les uns et les autres), font apparaitre des
contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ,
y'avait une simple notice technique, pas forcément en accord avec un modèle
théorique parfait, mais répondant à des problèmes généralement trés terre à
terre.
Non, pas de but précis, juste le désir de comprendre ce que je lis.
J'ai développé des systèmes d'exploitation sur des cartes à puce, et
suis curieux de comprendre comment d'autres systèmes d'exploitation
peuvent fonctionner.
D'où mon étude actuelle sur le système d'exploitation Windows.
De rien, J'aurais aimé savoir si tout cela avait un but précis, vous faites un bouquin ? des cours ? etc...
Parfois, l'aspect conceptuel des couches d'abstractions, construites au cours du temps (par les uns et les autres), font apparaitre des contradictions ou des zones d'ombre, d'autant qu'on oublie qu'au départ, y'avait une simple notice technique, pas forcément en accord avec un modèle théorique parfait, mais répondant à des problèmes généralement trés terre à terre.
Non, pas de but précis, juste le désir de comprendre ce que je lis.
J'ai développé des systèmes d'exploitation sur des cartes à puce, et suis curieux de comprendre comment d'autres systèmes d'exploitation peuvent fonctionner.
D'où mon étude actuelle sur le système d'exploitation Windows.
Bien cordialement
Papouille
Papouille
Juste pour conclure ce fil :
System Programming Guide d'Intel pour le Pentium :
"Interrupts generated in software with the INT n instruction cannot be masked by the IF flag in the EFLAGS register."
Vincent Burel a écrit :
y'a aussi des registres pour masquer les exceptions.
System Programming Guide d'Intel pour le Pentium :
"The processor first services a pending exception or interrupt from the class which has the highest priority, transferring execution to the first instruction of the handler. Lower priority exceptions are discarded; lower priority interrupts are held pending. Discarded exceptions are re-generated when the interrupt handler returns execution to the point in the program or task where the exceptions and/or interrupts occurred."
Donc les execptions ne sont pas masquables par registre. Les interruptions, si.
A quel registre pensiez-vous ?
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi ?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse facilement les ré-exposer au cours d'une discussion, et éviter de tomber dans des contradictions qui démontreraient notre manque de connaissance suffisante sur le sujet.
Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent au mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode kernel, mais une instruction dédiée : sysenter (pentium) pour entrer dans le kernel-mode et sysexit pour sortir du kernel-mode.
Le numéro du service-système demandé est stocké dans le registre EAX du microprocesseur avant l'exécution de systenter.
L'exécution de sysenter provoque automatiquement l'exécution de la routine KiSystemService (de NtOsKrnl.exe) qui analysera les arguments (stockés dans la pile kernel du microprocesseur) avnt d'exécuter le service demandé.
Ce système n'est donc pas comparable à celui d'une instruction CALL, mais plutôt à celui d'une interruption software (à peu de choses près).
Juste pour conclure ce fil :
System Programming Guide d'Intel pour le Pentium :
"Interrupts generated in software with the INT n instruction cannot be
masked by the IF flag in the EFLAGS register."
Vincent Burel a écrit :
y'a aussi des registres pour masquer les exceptions.
System Programming Guide d'Intel pour le Pentium :
"The processor first services a pending exception or interrupt from the
class which has
the highest priority, transferring execution to the first instruction of
the handler. Lower priority
exceptions are discarded; lower priority interrupts are held pending.
Discarded exceptions are
re-generated when the interrupt handler returns execution to the point
in the program or task
where the exceptions and/or interrupts occurred."
Donc les execptions ne sont pas masquables par registre. Les
interruptions, si.
A quel registre pensiez-vous ?
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi ?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse
facilement les ré-exposer au cours d'une discussion, et éviter de tomber
dans des contradictions qui démontreraient notre manque de connaissance
suffisante sur le sujet.
Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent au
mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode
kernel, mais une instruction dédiée : sysenter (pentium) pour entrer
dans le kernel-mode et sysexit pour sortir du kernel-mode.
Le numéro du service-système demandé est stocké dans le registre EAX du
microprocesseur avant l'exécution de systenter.
L'exécution de sysenter provoque automatiquement l'exécution de la
routine KiSystemService (de NtOsKrnl.exe) qui analysera les arguments
(stockés dans la pile kernel du microprocesseur) avnt d'exécuter le
service demandé.
Ce système n'est donc pas comparable à celui d'une instruction CALL,
mais plutôt à celui d'une interruption software (à peu de choses près).
System Programming Guide d'Intel pour le Pentium :
"Interrupts generated in software with the INT n instruction cannot be masked by the IF flag in the EFLAGS register."
Vincent Burel a écrit :
y'a aussi des registres pour masquer les exceptions.
System Programming Guide d'Intel pour le Pentium :
"The processor first services a pending exception or interrupt from the class which has the highest priority, transferring execution to the first instruction of the handler. Lower priority exceptions are discarded; lower priority interrupts are held pending. Discarded exceptions are re-generated when the interrupt handler returns execution to the point in the program or task where the exceptions and/or interrupts occurred."
Donc les execptions ne sont pas masquables par registre. Les interruptions, si.
A quel registre pensiez-vous ?
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi ?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse facilement les ré-exposer au cours d'une discussion, et éviter de tomber dans des contradictions qui démontreraient notre manque de connaissance suffisante sur le sujet.
Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent au mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode kernel, mais une instruction dédiée : sysenter (pentium) pour entrer dans le kernel-mode et sysexit pour sortir du kernel-mode.
Le numéro du service-système demandé est stocké dans le registre EAX du microprocesseur avant l'exécution de systenter.
L'exécution de sysenter provoque automatiquement l'exécution de la routine KiSystemService (de NtOsKrnl.exe) qui analysera les arguments (stockés dans la pile kernel du microprocesseur) avnt d'exécuter le service demandé.
Ce système n'est donc pas comparable à celui d'une instruction CALL, mais plutôt à celui d'une interruption software (à peu de choses près).
Vincent Burel
"Papouille" wrote in message news:49327b66$0$10781$
Juste pour conclure ce fil : "Interrupts generated in software with the INT n instruction cannot be masked by the IF flag in the EFLAGS register."
Ben oui, le INT 'n' appelle la fonction pointée par le vecteur 'n' de la table de vecteur de "linterrupt handler" donc ca ne peut pas se masquer par un FLAG. Je parlais des interruption matérielles.
Donc les execptions ne sont pas masquables par registre. Les interruptions, si.
Il me semble plus exactement que les exceptions qui sont masquables, peuvent se masquer par un registre du processor, les interruptions (matérielles) par un registre du PIC (programmable Interrupt Controler) port 0x0020.
A quel registre pensiez-vous ?
Je pensais par exemple au Control WORD du FPU dont les 6 premiers bits sont des mask d'exception (d'ailleurs à 1 après un FINIT).
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi
?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse facilement les ré-exposer au cours d'une discussion, et éviter de tomber dans des contradictions qui démontreraient notre manque de connaissance suffisante sur le sujet.
bon, pourvu que ca marche ! :-)
> Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent
au
> mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode kernel, mais une instruction dédiée : sysenter (pentium) pour entrer dans le kernel-mode et sysexit pour sortir du kernel-mode.
Ha oui !? Il me semble qu'un SYSENTER (arrivé avec le Pentium II) n'est rien de plus plus qu'un long CALL optimisé pour les appels systèmes...
Ce système n'est donc pas comparable à celui d'une instruction CALL, mais plutôt à celui d'une interruption software (à peu de choses près).
Ce que vous appelez le "peu de chose prés" c'est la nature "non interruptible" d'une "fonction" appelée par un INT. Ce qui n'est pas le cas d'une "fonction" appelée par un CALL ou un SYSENTER.
bref... VB
"Papouille" <Papouille@papouille.net> wrote in message
news:49327b66$0$10781$426a34cc@news.free.fr...
Juste pour conclure ce fil :
"Interrupts generated in software with the INT n instruction cannot be
masked by the IF flag in the EFLAGS register."
Ben oui, le INT 'n' appelle la fonction pointée par le vecteur 'n' de la
table de vecteur de "linterrupt handler" donc ca ne peut pas se masquer par
un FLAG. Je parlais des interruption matérielles.
Donc les execptions ne sont pas masquables par registre. Les
interruptions, si.
Il me semble plus exactement que les exceptions qui sont masquables, peuvent
se masquer par un registre du processor, les interruptions (matérielles) par
un registre du PIC (programmable Interrupt Controler) port 0x0020.
A quel registre pensiez-vous ?
Je pensais par exemple au Control WORD du FPU dont les 6 premiers bits sont
des mask d'exception (d'ailleurs à 1 après un FINIT).
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi
?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse
facilement les ré-exposer au cours d'une discussion, et éviter de tomber
dans des contradictions qui démontreraient notre manque de connaissance
suffisante sur le sujet.
bon, pourvu que ca marche ! :-)
> Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent
au
> mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode
kernel, mais une instruction dédiée : sysenter (pentium) pour entrer
dans le kernel-mode et sysexit pour sortir du kernel-mode.
Ha oui !? Il me semble qu'un SYSENTER (arrivé avec le Pentium II) n'est rien
de plus plus qu'un long CALL optimisé pour les appels systèmes...
Ce système n'est donc pas comparable à celui d'une instruction CALL,
mais plutôt à celui d'une interruption software (à peu de choses près).
Ce que vous appelez le "peu de chose prés" c'est la nature "non
interruptible" d'une "fonction" appelée par un INT. Ce qui n'est pas le cas
d'une "fonction" appelée par un CALL ou un SYSENTER.
"Papouille" wrote in message news:49327b66$0$10781$
Juste pour conclure ce fil : "Interrupts generated in software with the INT n instruction cannot be masked by the IF flag in the EFLAGS register."
Ben oui, le INT 'n' appelle la fonction pointée par le vecteur 'n' de la table de vecteur de "linterrupt handler" donc ca ne peut pas se masquer par un FLAG. Je parlais des interruption matérielles.
Donc les execptions ne sont pas masquables par registre. Les interruptions, si.
Il me semble plus exactement que les exceptions qui sont masquables, peuvent se masquer par un registre du processor, les interruptions (matérielles) par un registre du PIC (programmable Interrupt Controler) port 0x0020.
A quel registre pensiez-vous ?
Je pensais par exemple au Control WORD du FPU dont les 6 premiers bits sont des mask d'exception (d'ailleurs à 1 après un FINIT).
Mouai, et concrétement faire une distinction aussi fine, ca apporte quoi
?
Cela permet d'avoir les idées claires, de telle façon qu'on puisse facilement les ré-exposer au cours d'une discussion, et éviter de tomber dans des contradictions qui démontreraient notre manque de connaissance suffisante sur le sujet.
bon, pourvu que ca marche ! :-)
> Pas tout a fait, le mécanisme d'interruption (INT) n'est pas equivalent
au
> mécanisme d'appel (CALL).
Windows n'utilise pas de CALL pour exécuter une routine système en mode kernel, mais une instruction dédiée : sysenter (pentium) pour entrer dans le kernel-mode et sysexit pour sortir du kernel-mode.
Ha oui !? Il me semble qu'un SYSENTER (arrivé avec le Pentium II) n'est rien de plus plus qu'un long CALL optimisé pour les appels systèmes...
Ce système n'est donc pas comparable à celui d'une instruction CALL, mais plutôt à celui d'une interruption software (à peu de choses près).
Ce que vous appelez le "peu de chose prés" c'est la nature "non interruptible" d'une "fonction" appelée par un INT. Ce qui n'est pas le cas d'une "fonction" appelée par un CALL ou un SYSENTER.
