| 11 | | * Une interruption matérielle est asynchrone (on ne peut pas savoir quand elle va se produire) et elle n'a que très peu d'effet sur le programme A en cours d'exécution, car le programme B qui a demandé l'opération d'entrée sortie qui est la cause de l'interruption n'est généralement pas en cours d'exécution quand l'opération d'entrée/sortie se termine. Le programme A en cours d'exécution va seulement perdre quelques centaines de cycles, qui vont donc le retarder d'autant, mais il reprendra son exécution au point où il en était, sans autre modifications quand l'ISR se termine. |
| 12 | | * Une exception matérielle se produit quand une instruction particulière X d'un programme essaie de faire quelque chose d'illégal ou d'impossible, généralement à cause d'une erreur de programmation (division par zéro, erreur d'adressage, etc.) C'est donc un événement synchrone et reproductible : il se reproduira à la même instruction X si on essaie de re-exécuter le programme sans le modifier. Et c'est presque toujours un événement mortel pour le programme fautif, qui est généralement tué par l'OS, avec message d'erreur pour aider au debug. |
| | 11 | * Une interruption matérielle est asynchrone (on ne peut pas savoir quand elle va se produire) et elle n'a que très peu d'effet sur le programme A en cours d'exécution, car le programme B qui a demandé l'opération d'entrée sortie, et qui est la cause de l'interruption, n'est généralement pas en cours d'exécution quand l'opération d'entrée/sortie se termine. Le programme A en cours d'exécution va seulement perdre quelques centaines de cycles, qui vont donc le retarder d'autant, mais il reprendra son exécution au point où il en était, sans autre modifications quand l'ISR se termine. |
| | 12 | * Une exception matérielle se produit quand une instruction particulière X d'un programme A essaie de faire quelque chose d'illégal ou d'impossible, généralement à cause d'une erreur de programmation (division par zéro, erreur d'adressage, etc.) C'est donc un événement synchrone et reproductible : il se reproduira à la même instruction X si on essaie de re-exécuter le programme A sans le modifier. Et c'est presque toujours un événement mortel pour le programme fautif, qui est généralement tué par l'OS, avec message d'erreur pour aider au debug. |
| 16 | | Le gestionnaire d'interruption du GIET n'est pas re-entrant. Lorsque le processeur se branche au GIET parce qu'une interruption IRQ_1, non masquée, a été détectée, le bit d'autorisation des interruptions du register SR (bit IE) est systématiquement mis à 0, pour que le GIET commence à s'exécuter avec les interruptions masquées. Mais le gestionnaire d'interruption ne remet pas à ce bit à 1, et donc le traitement de l'interruption IRQ_1, y compris l'exécution de l'ISR associée à IRQ_1 ne peuvent être interrompus par l'autre interruption IRQ_2. Par conséquent l'interruption IRQ_2 ne sera prise en compte que lorsque les gestionnaire d'interruption redonne la main au programme utilisateur interrompu par IRQ_1. En effet l'instruction "eret" remet à 1 le bit IM, |
| 17 | | car un programme utilisateur en mode utilisateur doit toujours être interruptible. En d'autre termes, le GIET traite les interruptions l'une après l'autre, et le traitement d'une interruption n'est pas interruptible. Certains systèmes d'exploitation utilisent des gestionnaires d'interruptions re-entrant, c'est à dire que le gestionnaire d'interruption est lui-même interruptible. Mais cela complique significativement l'écriture du Gestionnaire d'Interruption, car il faut alors utiliser une technique de pile pour sauvegarder les contextes. |
| | 16 | Le gestionnaire d'interruption du GIET n'est pas re-entrant. Lorsque le processeur se branche au GIET parce qu'une interruption IRQ_1, non masquée, a été détectée, le bit d'autorisation des interruptions du register SR (bit IE) est systématiquement mis à 0, pour que le GIET commence à s'exécuter avec les interruptions masquées. Mais le gestionnaire d'interruption ne remet pas à ce bit à 1, et donc le traitement de l'interruption IRQ_1, y compris l'exécution de l'ISR associée à IRQ_1 ne peuvent être interrompus par la seconde interruption IRQ_2. Par conséquent l'interruption IRQ_2 ne sera prise en compte que lorsque les gestionnaire d'interruption redonne la main au programme utilisateur interrompu par IRQ_1. En effet l'instruction "eret" remet à 1 le bit IM, car un programme en mode utilisateur doit toujours être interruptible. En d'autre termes, le GIET traite les interruptions l'une après l'autre, et le traitement d'une interruption n'est pas interruptible. Certains systèmes d'exploitation utilisent des gestionnaires d'interruptions re-entrant, c'est à dire que le gestionnaire d'interruption est lui-même interruptible. Mais cela complique significativement l'écriture du Gestionnaire d'Interruption, car il faut alors utiliser une technique de pile pour sauvegarder les contextes. |
