Changes between Version 17 and Version 18 of Archi-1-TP11

Timestamp:

Dec 10, 2021, 5:54:50 AM (3 years ago)

Author:

franck

Comment:

--

Archi-1-TP11

@@ -35 +35 @@
 Il est fortement recommandé de lire les transparents, toutefois, nous avons ajouté ci-après quelques rappels utiles pour répondre aux questions du TD.
 
+Dans cette séance, noua allons manipuler 3 contrôleurs de périphériques: Le TTY que vous connaissez déjà et deux autres, l'ICU et le TIMER. Ces trois contrôleurs s'utilisent grâce à des registres mappés (placés) dans l'espace d'adressage du MIPS. Les registres du TTY sont placés à partir de l'adresse `0xd0200000`, ceux de l'ICU à partir de l'adresse `0xd1200000` et enfin ceux du TIMER à partir de l'adresse `0xd3200000`. L'explication du rôle de ces registres est rappelée en partie dans ce texte et pour le détail, vous devez revoir le cours.
+Le choix des adresses de ces contrôleurs est fait par le créateur du matériel, elles ne peuvent pas être changées par le logiciel. Ces adresses sont données dans le fichier ldscript du kernel (`kernel.ld`) parce qu'elles ne sont utilisables que si le MIPS est en mode kernel (adresses > `0x80000000`).
+
+[[Image(htdocs:img/device_registers.png,nolink,height=180)]]
+
 Les IRQ (Interrupt !ReQuest)s sont des signaux électriques à 2 états (ON/OFF ou !Actif/Inactif ou encore !Levé/Baissé). Les IRQ sont levés par les contrôleurs de périphériques pour prévenir d'un événement (fin de commande, arrivée d'une donnée, etc.). Les IRQs provoquent l'exécution d'ISR (Interrupt Service Routine) par le noyau. Les ISR sont des fonctions qui reçoivent en argument un identifiant du contrôleur de périphérique qui a levé l'IRQ. Une ISR doit faire deux choses, (1) accéder aux registres du contrôleur de périphérique concerné pour faire ce que le périphérique demande et (2) acquitter l'IRQ, c'est-à-dire demander au contrôleur de périphérique de baisser/désactiver son IRQ (puisque celle-ci a été traitée).
 
@@ -47 +52 @@
 [[Image(htdocs:img/IRQ_routage.png,nolink,height=200)]]
 
-Sur le schéma ci-dessu:s, on voit que l'IRQ du TTY0 entre sur l'entrée n°`10` de l'ICU, c'est un choix matériel qui n'est pas modifiable par logiciel. Son état est donc enregistré dans le bit n°10 du registre `ICU_STATE`. Il y a un `AND` avec le bit `10` du registre `ICU_MASK`. Si le bit `10` du registre `ICU_MASK` est à `0`, alors la sortie du `AND` est `0` et l'IRQ est masquée (donc invisible pour le processeur). Le registre `ICU_HIGHEST` contient toujours le numéro de l'IRQ active la plus prioritaire, comme il n'y en a qu'une dans cet exemple, `ICU_HIGHEST` contient `10`. L'IRQ de l'ICU entre sur l'entrée `0` des 6 IRQs possibles du MIPS et sa valeur s'inscrit dans le registre `HWI0` du registre `C0_CAUSE`. Il y a un `AND` avec le bit `HWI0` du registre `C0_STATUS`. Si le bit `HWI0` du registre `C0_STATUS` est à 0, alors la sortie du `AND` est `0` et l'IRQ est aussi masquée. Enfin, il y a encore un `AND` qui permet de masquer globalement les IRQ avec le bit `0` de `C0_STATUS` (c'est le bit `IE` pour Interrupt Enable) et le `NOT` du bit `1` de `C0_STATUS` (c'est le bit `EXL` EXception Level). 
-
-Quand le signal IRQ vue par le MIPS s'active (passe à 1), c'est que l'IRQ levée par le contrôleur de périphérique doit être prise en charge. Le programme en cours est interrompu et dérouté vers `kentry` à l'adresse `0x80000180` et en même temps `C0_EPC ← PC+4`, `C0_CAUSE.XCODE ← 0`, `C0_STATUS.EXL ← 1`. Notez que le nom officiel de `C0_STATUS` est `C0_SR` mais dans ce document, on utilise `C0_STATUS` pour plus de clarté.
+Sur le schéma ci-dessus, on voit que l'IRQ du TTY0 entre sur l'entrée n°`10` de l'ICU, c'est un choix matériel qui n'est pas modifiable par logiciel. Son état est donc enregistré dans le bit n°10 du registre `ICU_STATE`. Il y a un `AND` avec le bit `10` du registre `ICU_MASK`. Si le bit `10` du registre `ICU_MASK` est à `0`, alors la sortie du `AND` est `0` et l'IRQ est masquée (donc invisible pour le processeur). Le registre `ICU_HIGHEST` contient toujours le numéro de l'IRQ active la plus prioritaire, comme il n'y en a qu'une dans cet exemple, `ICU_HIGHEST` contient `10`. L'IRQ de l'ICU entre sur l'entrée `0` des 6 IRQs possibles du MIPS et sa valeur s'inscrit dans le registre `HWI0` du registre `C0_CAUSE`. Il y a un `AND` avec le bit `HWI0` du registre `C0_STATUS`. Si le bit `HWI0` du registre `C0_STATUS` est à 0, alors la sortie du `AND` est `0` et l'IRQ est aussi masquée. Enfin, il y a encore un `AND` qui permet de masquer globalement les IRQ avec le bit `0` de `C0_STATUS` (c'est le bit `IE` pour Interrupt Enable) et le `NOT` du bit `1` de `C0_STATUS` (c'est le bit `EXL` EXception Level). 
+
+Quand le signal IRQ vue par le MIPS s'active (passe à 1), c'est que l'IRQ levée par le contrôleur de périphérique doit être prise en charge. Le programme en cours est interrompu et dérouté vers `kentry` à l'adresse `0x80000180` et en même temps `C0_EPC ← PC+4`, `C0_CAUSE.XCODE ← 0`, `C0_STATUS.EXL ← 1`. Notez que le nom officiel de `C0_STATUS` est `C0_SR`, mais dans ce document, on utilise `C0_STATUS` pour plus de clarté.
 
 
@@ -55 +60 @@
 
 Dans le schéma précédent, à gauche c'est le matériel et à droite c'est un extrait de la RAM contenant les structures de données utilisées par le noyau.
-- À gauche, on voit que les IRQ venant des contrôleurs de périphériques sont connectés aux entrées d'IRQ de l'ICU. Il y a 32 entrées possibles. Sur notre plateforme, par exemple l'IRQ du TTY2 est connectée à l'entrée `12` de l'ICU. Ce numéro d'entrée est le numéro qui identifie le contrôleur de périphérique. Notez que le registre `ICU_MASK` est en lecture seul, c'est-à-dire qu'il ne peut pas être écrit directement. Pour modifier le contenu du registre `ICU_MASK`, il faut utiliser deux autres registres de l'`ICU`: `ICU_SET` et `ICU_CLEAR`. `ICU_SET` permet de mettre à `1` les bits de `ICU_MASK`, et `ICU_CLEAR` permet de les mettre à `0`. Pour mettre à `1` le bit `i` du registre `ICU_MASK`, il faut écrire `1` dans le bit `i` du registre `ICU_SET`. Pour mettre à `0` le bit `j` du registre `ICU_MASK`, il faut aussi écrire `1` mais dans le bit `j` du registre `ICU_CLEAR`.\\\\
-- À droite, il y a les deux tableaux que le noyau utilise pour connaitre l'ISR à exécuter pour chaque numéro IRQ. Ce couple de tableaux se nomme **vecteur d'interruption**. Ici, il est composé des tableaux `IRQ_VECTOR_ISR[]` et `IRQ_VECTOR_DEV[]`. Le vecteur d'interruption est indexé par les numéros d'IRQ. Il contient deux informations: (1) Dans la case n°`i` du tableau `IRQ_VECTOR_ISR[]`, on trouve le pointeur sur la fonction ISR a appeler si l'IRQ n°`i` est levée, et (2) dans la case n°`i` du tableau `IRQ_VECTOR_DEV[]`, on trouve le numéro de l'instance du périphérique. Cette dernière information est nécessaire dans le cas des contrôleurs de périphérique multi-instances comme le TTY afin de savoir quel jeu de registres la fonction ISR doit utiliser. En d'autres termes, Il y a une fonction ISR unique quelque-soit le numéro du TTY, l'adresse de cette fonction est placée dans les cases `10`, `11`, `12`, et `13` du tableau `IRQ_VECTOR_ISR[]` (si on a 4 TTYs) et dans les cases  `10`, `11`, `12`, et `13` du tableau `IRQ_VECTOR_DEV[]`, on a `0`, `1`, `2` et `3` qui correspondent bien au numéro d'instance des TTYs. 
+- À gauche, on voit que les IRQ venant des contrôleurs de périphériques sont connectés aux entrées d'IRQ de l'ICU. Il y a 32 entrées possibles. Sur notre plateforme, par exemple l'IRQ du TTY2 est connectée à l'entrée `12` de l'ICU. Ce numéro d'entrée est le numéro qui identifie le contrôleur de périphérique. Notez que le registre `ICU_MASK` est en lecture seul, c'est-à-dire qu'il ne peut pas être écrit directement. Pour modifier le contenu du registre `ICU_MASK`, il faut utiliser deux autres registres de l'`ICU`: `ICU_SET` et `ICU_CLEAR`. `ICU_SET` permet de mettre à `1` les bits de `ICU_MASK`, et `ICU_CLEAR` permet de les mettre à `0`. Pour mettre à `1` le bit `i` du registre `ICU_MASK`, il faut écrire `1` dans le bit `i` du registre `ICU_SET`. Pour mettre à `0` le bit `j` du registre `ICU_MASK`, il faut aussi écrire `1`, mais dans le bit `j` du registre `ICU_CLEAR`.\\\\
+- À droite, il y a les deux tableaux que le noyau utilise pour connaitre l'ISR à exécuter pour chaque numéro IRQ. Ce couple de tableaux se nomme **vecteur d'interruption**. Ici, il est composé des tableaux `IRQ_VECTOR_ISR[]` et `IRQ_VECTOR_DEV[]`. Le vecteur d'interruption est indexé par les numéros d'IRQ. Il contient deux informations: (1) Dans la case n°`i` du tableau `IRQ_VECTOR_ISR[]`, on trouve le pointeur sur la fonction ISR à appeler si l'IRQ n°`i` est levée, et (2) dans la case n°`i` du tableau `IRQ_VECTOR_DEV[]`, on trouve le numéro de l'instance du périphérique. Cette dernière information est nécessaire dans le cas des contrôleurs de périphérique multi-instances comme le TTY afin de savoir quel jeu de registres la fonction ISR doit utiliser. En d'autres termes, il y a une fonction ISR unique quelque-soit le numéro du TTY, l'adresse de cette fonction est placée dans les cases `10`, `11`, `12`, et `13` du tableau `IRQ_VECTOR_ISR[]` (si on a 4 TTYs) et dans les cases  `10`, `11`, `12`, et `13` du tableau `IRQ_VECTOR_DEV[]`, on a `0`, `1`, `2` et `3` qui correspondent bien au numéro d'instance des TTYs. 
 
 [[Image(htdocs:img/C0_registers.png,nolink,height=300)]]
@@ -91 +96 @@
 {{{#!protected ------------------------------------------------------------------------------------
 ''
-  * Les composants source sont les contrôleurs de périphériques par exemple le `TTY` et les composants destinataires sont les processeurs (ici le MIPS).
+  * Les composants sources sont les contrôleurs de périphériques par exemple le `TTY` et les composants destinataires sont les processeurs (ici le MIPS).
 ''
 }}}
@@ -97 +102 @@
 {{{#!protected ------------------------------------------------------------------------------------
 ''
-  * Cela signifie que l'on bloque le signal entre sa source et sa destination. Si une IRQ est levée par un contrôleur de périphérique et que l'on masque cette IRQ, alors l'IRQ est toujours levée à sa source mais le MIPS destinaire ne le voit pas. L'information, le signal, a été masqué sur le chemin entre la source et la destination. Cette IRQ devient invisible pour le MIPS.
+  * Cela signifie que l'on bloque le signal entre sa source et sa destination. Si une IRQ est levée par un contrôleur de périphérique et que l'on masque cette IRQ, alors l'IRQ est toujours levée à sa source, mais le MIPS destinataire ne le voit pas. L'information, le signal, a été masquée sur le chemin entre la source et la destination. Cette IRQ devient invisible pour le MIPS.
 ''
 }}}
@@ -109 +114 @@
 {{{#!protected ------------------------------------------------------------------------------------
 ''
-  * Non, puisque que pour masquer une interruption, il faut écrire dans les registres de l'ICU ou dans les registres système du processeur. Or, les registres de configuration de l'ICU sont mappés dans le partie de l'espace d'adressage inaccessible en mode user et que les instructions `mfc0` et `mtc0` sont interdites en mode user, leur usage provoque une exception de type violation de privilège.
+  * Non, puisque pour masquer une interruption, il faut écrire dans les registres de l'ICU ou dans les registres système du processeur. Or, les registres de configuration de l'ICU sont mappés dans la partie de l'espace d'adressage inaccessible en mode user et que les instructions `mfc0` et `mtc0` sont interdites en mode user, leur usage provoque une exception de type violation de privilège.
 ''
 }}}
@@ -148 +153 @@
 ''
 }}}
-1. Que signifie acquiter une IRQ et qui le demande à qui ?
+1. Que signifie acquitter une IRQ et qui le demande à qui ?
 {{{#!protected ------------------------------------------------------------------------------------
 ''
@@ -163 +168 @@
 {{{#!protected ------------------------------------------------------------------------------------
 ''
-  * Non, le noyau ne doit pas surpris par une IRQ, il doit avoir une ISR prévue. S'il doit traiter une IRQ non prévue, il affiche un message d'erreur, puis il masque cette IRQ dans l'ICU. Cela ne devrait jamais arriver.
+  * Non, le noyau ne doit pas être surpris par une IRQ, il doit avoir une ISR prévue. S'il doit traiter une IRQ non prévue, il affiche un message d'erreur, puis il masque cette IRQ dans l'ICU. Cela ne devrait jamais arriver.
 ''
 }}}
@@ -187 +192 @@
 {{{#!protected ------------------------------------------------------------------------------------
 ''
-  * Le gestionnaire d'interruption doit déterminer le numéro de l'IRQ en lisant dans le registre `ICU_HIGHEST` de l'ICU et il doit appeler la fonction ISR trouvée dans le tableau `IRQ_VECTOR_ISR[]` du vecteur d'interruption à la case du numéro de l'IRQ, en lui donnant en argument le numéro du device trouvé dans le tableau `IRQ_VECTOR_DEV[]` à la case du numéro de l'IRQ.
-''
-}}}
-1. À l'entrée dans le noyau, `kentry` analyse le champ `XCODE` du registre de `c0_cause` et si c'est `0` alors il saut au code donné ci-après (ce n'est pas exactement le code que vous pouvez voir dans les fichiers source pour que ce soit plus facile à comprendre).
+  * Le gestionnaire d'interruption doit déterminer le numéro de l'IRQ en lisant dans le registre `ICU_HIGHEST` de l'ICU et il doit appeler la fonction ISR trouvée dans le tableau `IRQ_VECTOR_ISR[]` du vecteur d'interruption à la case du numéro de l'IRQ, en lui donnant en argument le numéro du périphérique (DEVice) trouvé dans le tableau `IRQ_VECTOR_DEV[]` à la case du numéro de l'IRQ.
+''
+}}}
+1. À l'entrée dans le noyau, `kentry` analyse le champ `XCODE` du registre de `c0_cause` et si c'est `0` alors il saut au code donné ci-après (ce n'est pas exactement le code que vous pouvez voir dans les fichiers sources pour que ce soit plus facile à comprendre).
 {{{#!c
 cause_irq:
@@ -223 +228 @@
 ''
 }}}
-1. La fonction `irq_handler()` a pour mission d'appeler la bonne ISR. Dans le code qui suit (extrait du fichier `kernel/harch.c`), on voit d'abord la déclaration de la structure qui décrit les registres présents dans l'ICU. En fait c'est un tableau de structure parce qu'il y a autant d'instance d'ICU que de processeurs (donné par NCPUS), ici, il y a un seul processeur MIPS, donc NCPUS=1.
+1. La fonction `irq_handler()` a pour mission d'appeler la bonne ISR. Dans le code qui suit (extrait du fichier `kernel/harch.c`), on voit d'abord la déclaration de la structure qui décrit les registres présents dans l'ICU. En fait c'est un tableau de structure parce qu'il y a autant d'instances d'ICU que de processeurs (donné par NCPUS), ici, il y a un seul processeur MIPS, donc NCPUS=1.
 {{{#!c
 struct icu_s {
@@ -303 +308 @@
 ''
 }}}
-1. On a vu qu'un syscall est comme un appel de fonction, il ne garantie pas que les registres temporaires sont conservés, mais il garantit que les registres persistants le sont. est-ce que c'est pareil pour les interruptions ?
+1. On a vu qu'un syscall est comme un appel de fonction, il ne garantie pas que les registres temporaires sont conservés, mais il garantit que les registres persistants le sont. Est-ce que c'est pareil pour les interruptions ?
 {{{#!protected ------------------------------------------------------------------------------------
 ''
@@ -319 +324 @@
 == Game Over
 
-Dans le premier TME, vous avez réalisé un petit jeux dans lequel vous deviez deviner un nombre tirer au hasard. Ce jeu avait été mis dans kinit parce qu'a ce moment, il n'y avait pas encore d'application utilisateur. Nous vous proposons de mettre le jeu dans l'application user et de limiter le temps pendant lequel vous pouvez jouer.
+Dans le premier TME, vous avez réalisé un petit jeu dans lequel vous deviez deviner un nombre tiré au hasard. Ce jeu avait été mis dans kinit parce qu'a ce moment, il n'y avait pas encore d'application utilisateur. Nous vous proposons de mettre le jeu dans l'application user et de limiter le temps pendant lequel vous pouvez jouer.
 
 Modifier l'ISR du timer pour afficher "Game Over"