Changes between Version 53 and Version 54 of Doc-MIPS-Archi-Asm-kernel

Timestamp:

Nov 13, 2020, 8:17:08 PM (5 years ago)

Author:

franck

Comment:

--

Doc-MIPS-Archi-Asm-kernel

@@ -200 +200 @@
  CPU::  Coprocesseur inaccessible : tentative d'exécution d'une instruction privilégiée (`mtc0`, `mfc0`, `eret`) alors que le processeur est en mode ''user''.
 
-Dans tous les cas, le processeur doit passer en mode ''kernel'' et se brancher au noyau du système d'exploitation implanté à l'adresse `0x80000180`. 
-Lorsque le processeur détecte une exception, il réalise les opérations suivantes :
+Dans tous les cas, le processeur doit passer en mode ''kernel'' et se brancher au noyau du système d'exploitation implanté à l'adresse `0x80000180`. De manière plus détaillée, lorsque le processeur détecte une exception, il réalise les opérations suivantes (le fonctionnement des registres de cause (`C0_CAUSE`) et de status (`C0_SR`) est détaillé dans les section 6. et 7.) :
  - sauvegarde du registre `PC` (l'adresse de l'instruction fautive) dans le registre `C0_EPC` ;
  - passage en mode ''kernel'' et masquage les interruptions en mettant `1` dans le bit EXL de `C0_SR` ; 
@@ -208 +207 @@
  - branchement à l'adresse `0x80000180`.
 
-Après avoir identifié que la cause est une exception (en examinant le contenu du registre `C0_CAUSE`), le noyau se branche alors au gestionnaire d’exception. Ici, toutes les exceptions sont fatales, il n'y a pas de reprise de l'exécution de l'application contenant l'instruction fautive. 
-Le processeur doit cependant transmettre au gestionnaire d'exceptions l'adresse de l'instruction fautive et indiquer dans le registre de cause le type d'exception détectée. 
-
-
+Pour information, après avoir identifié que la cause d'entrée est une exception (en examinant le contenu du registre `C0_CAUSE`), le noyau se branche au gestionnaire d’exception. Ici, toutes les exceptions sont fatales, il n'y a pas de reprise de l'exécution de l'application contenant l'instruction fautive. 
 
 
@@ -220 +216 @@
 Les périphériques reçoivent des commandes dans leur registres par des instructions de lecture et d'écriture (`lw`/`sw`) venant du processeur. 
 
-Lorsqu'ils ont terminées une commande ou lorsqu'ils ont reçus ou calculés des données, les contrôleurs de périphérique peuvent le signaler au processeur par des **requêtes d'interruption** (IRQ pour Interrupt Request en anglais).
+Lorsqu'ils ont terminées une commande ou lorsqu'ils ont reçus ou calculés des données, les contrôleurs de périphériques peuvent le signaler au processeur par des **requêtes d'interruption** (IRQ pour Interrupt Request en anglais).
 Une requête d'interruption est un signal d'état produit par un contrôleur de périphérique avec deux états possibles : **actif** (ou levé) qui signifie que le contrôleur demande que le noyau intervienne ou **inactif** (ou baissé) qui signifie que le contrôleur n'a pas de demande. 
-Les requête d'interruptions sont donc des notifications de fins de commandes, d'arrivée de données sur un canal d'entrée ou encore des tick d'horloge. 
-
-Les requêtes d'interruption sont envoyées par des ''lignes d'interruption'' qui relie les contrôleurs de périphériques au processeur.
-Une ''ligne d'interruption'' est un fil électrique qui peut prendre les deux états des requêtes : actif/inactif, ou levé/baissé.
-
-Les requêtes d'interruption s'activent de manière asynchrone par rapport au programme en cours d'exécution sont des évènements asynchrones provenant des contrôleurs de périphériques. Ces évènements sont toujours attendus par le noyau du système d'exploitation. 
-
+Les requêtes d'interruptions sont donc des notifications de fins de commandes ou d'arrivée de données sur un canal d'entrée ou encore des ticks d'horloge. 
+
+Les requêtes d'interruption sont envoyées par des ''lignes d'interruption''.
+Une ''ligne d'interruption'' est un fil électrique  qui relie un contrôleur de périphérique au processeur et qui peut prendre les deux états des requêtes : actif/inactif (ou levé/baissé).
 Le processeur MIPS32 possède 6 entrées de lignes d'interruptions externes qui peuvent être masquées globalement ou individuellement. Masquer une interruption signifie ne pas en tenir compte. Nous n'utiliserons qu'une seule de ces 6 entrées dans le prototype des TP. 
 
-Les lignes d'interruption peuvent être actives ou inactives (on dit aussi levées ou baissées). L'activation d'une de ces lignes est une requête d'interruption provenant d'un contrôleur de périphérique. 
-
 Si elles ne sont pas masquées alors elles sont prises en compte à la fin de l'exécution de l'instruction en cours. Une requête émise par un contrôleur de périphérique doit être maintenue active par le contrôleur tant qu'elle n'a pas été prise en compte par le noyau du système d'exploitation.
+
+Même si l'activation d'une ligne d'interruption est toujours un événement attendu par le noyau du système d'exploitation, elle survient de manière asynchrone par rapport au programme en cours d'exécution.
+
 
 Le processeur doit alors passer alors en mode système et se brancher au noyau du système d'exploitation. Après avoir identifié que la cause est une interruption (en examinant le contenu du registre `c0_cause`), le noyau se branche au gestionnaire d’interruption qui doit appeler une fonction appropriée pour le traitement de la requête. Cette fonction est appelée routine d’interruption ou ISR (pour ''Interrupt Service Routine''). Comme il faut reprendre l'exécution de l'application en cours à la fin du traitement de l'interruption, il faut sauvegarder une adresse de retour. Lorsqu’il reçoit une requête d’interruption non masquée, le matériel  doit donc :