Changes between Initial Version and Version 1 of Archi-1-TD9

Timestamp:

Dec 4, 2021, 8:18:26 AM (4 years ago)

Author:

franck

Comment:

--

Archi-1-TD9

@@ +1 @@
+**
+[ __[wiki:WikiStart Start]__ ]
+[ __[wiki:Howto-TP Config]__ ]
+[ __[htdocs:cours/doc_MIPS32.pdf MIPS User]__ ]
+[ __[wiki:Doc-MIPS-Archi-Asm-kernel MIPS Kernel]__ ]
+—
+[ __[htdocs:cours/AS5-9-4p.pdf Cours 9]__ ]
+[ __[htdocs:cours/AS5-10-4p.pdf Cours 10]__ ]
+[ __[htdocs:cours/AS5-11-4p.pdf Cours 11]__ ]
+—
+[ ''TME 9'' ]
+[ __[https://www-soc.lip6.fr/trac/archi-l3s5/wiki/AS5-TME10 TME 10]__ ]
+[ __[https://www-soc.lip6.fr/trac/archi-l3s5/wiki/AS5-TME11 TME 11]__ ]
+**[[PageOutline]]**
+Codes (tgz) → 
+[ __[htdocs:files/kO6bin.tgz gcc & simulateur]__ ]
+[ __[htdocs:files/tp1.tgz TME 9]__ ]
+[ __[htdocs:files/tp2.tgz TME 10]__ ]
+[ __[htdocs:files/tp3.tgz TME 11]__ ]
+**
+{{{#!html
+<h1> <font size="+2"> Boot et premier programme en mode kernel
+</font></h1>
+}}}
+
+Cette page décrit la séance complète : TD et TP. Elle commence par des exercices à faire sur papier et puis elle continue et se termine par des questions sur le code et quelques exercices de codage simples à écrire et à tester sur le prototype.
+La partie pratique  est découpée en 5 étapes. Pour chaque étape, nous donnons (1) une brève description, (2) une liste des objectifs principaux de l'étape, (3) une liste des fichiers avec un bref commentaire sur chaque fichier, (4) une liste de questions simples dont les réponses sont dans le code, le cours ou le TD et enfin (5) un exercice de codage.
+
+**IMPORTANT\\Avant de faire cette séance, vous devez avoir lu les documents suivants** :
+* [wiki: Description des objectifs de cette séance et des suivantes] : ''obligatoire''
+* [htdocs:cours/AS5-9-4p.pdf Cours de démarrage présentant l'architecture matérielle et logicielle que vous allez manipuler] ''obligatoire''
+* [wiki:Howto-TP Configuration de l'environnement des TP] : ''obligatoire''
+* [htdocs:cours/doc_MIPS32.pdf Document sur l'assembleur du MIPS et la convention d'appel des fonctions] : ''recommandé, normalement déjà lu''
+* [wiki:Doc-MIPS-Archi-Asm-kernel Documentation sur le mode kernel du MIPS32] : ''optionnel pour cette séance''
+
+
+**Récupération du code du TP**
+
+* **Vous devez avoir installé le simulateur du prototype almo1 et la chaine de cross-compilation MIPS ([wiki:Howto-TP Config sections 2.2 et 3.2])**
+* Téléchargez **[htdocs:files/tp1.tgz l'archive code du tp1]** et placez là dans le répertoire **`~/kO6`** (ou dans le répertoire que vous avez choisi, relisez la page sur la configuration si ce n'est pas clair).  
+* Ouvrez un `terminal`
+* Allez dans le répertoire `kO6` : **`cd ~/kO6`**
+* Décompressez l'archive du tp1 (dans le répertoire **`kO6`**) : **`tar xvzf tp1.tgz`**
+* Exécutez la commande **`cd ; tree -L 1 kO6/tp1/`**.\\
+  ''(si vous n'avez pas `tree` sur votre Linux, vous pouvez l'installer, c'est un outil utile, mais pas indispensable pour ces TP)''\\
+  Vous devrez obtenir ceci:
+{{{#!bash
+kO6/tp1
+├── 1_hello_boot
+├── 2_init_asm
+├── 3_init_c
+├── 4_nttys
+├── 5_driver
+└── Makefile
+}}}
+
+
+
+== 
+= A. Travaux dirigés
+
+
+
+== A1. Analyse de l'architecture
+
+
+Les trois figures ci-dessous donnent des informations sur l'architecture du prototype **almo1** sur lequel vous allez travailler.
+* À gauche, vous avez un schéma simplifié.
+* Au centre, vous avez la représentation des 4 registres internes du contrôleur de terminal `TTY` nécessaires pour commander un couple écran-clavier.
+* À droite, vous avez la représentation de l'espace d'adressage du prototype.  
+
+[[Image(htdocs:img/almo1.png,nolink,height=300)]]
+[[Image(htdocs:img/TTY.png,nolink,height=200,top)]]
+[[Image(htdocs:img/espace_adresse.png,nolink,height=300)]]
+
+
+**Questions**
+
+1. Il y a deux mémoires dans **almo1** : RAM et ROM. Qu'est-ce qui les distinguent et que contiennent-elles ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 6 et 9
+* La ROM est une mémoire morte, c'est-à-dire en lecture seule. Elle contient le code de démarrage du prototype.
+* La RAM est une mémoire vive, c'est-à-dire pouvant être lue et écrite. Elle contient le code et les données.
+''
+}}}
+1. Qu'est-ce l'espace d'adressage du MIPS ? Quelle taille fait-il ?\\Quelles sont les instructions du MIPS permettant d'utiliser ces adresses ? Est-ce synonyme de mémoire ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 7
+* L'espace d'adressage du MIPS est l'ensemble des adresses que peut former le MIPS.
+* Les adresses sont sur 32 bits et désignent chacune un octet, il y a donc 2^32^ octets.
+* On accède à l'espace d'adressage avec les instructions load/store (`lw`, `lh`, `lb`, `lhu`, `lbu`, `sw`, `sh`, `sb`).
+* Non, les mémoires sont des composants contenant des cases de mémoire adressable. Les mémoires sont placées (on dit aussi « ''mappées'' » dans l'espace d'adressage).
+''
+}}}
+1. Dans quel composant matériel se trouve le code de démarrage et à quelle adresse est-il placé dans l'espace d'adressage et pourquoi à cette adresse ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 6 et 7
+* Le code de boot est dans la mémoire ROM.
+* Il commence à l'adresse `0xBFC00000` parce que c'est l'adresse qu'envoie le MIPS au démarrage. 
+''
+}}}
+1. Quel composant permet de faire des entrées-sorties dans almo1 ?\\Citez d'autres composants qui pourraient être présents dans un autre SoC ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 6 + connaissances personnelles
+* Ici, c'est le composant `TTY` qui permet de sortir des caractères sur un écran et de lire des caractères depuis un clavier.
+* Dans un autre SoC, on pourrait avoir un contrôleur de disque, un contrôleur vidéo, un port réseau Ethernet, un port USB, des entrées analogiques (pour mesurer des tensions), etc.
+''
+}}}
+1. Il y a 4 registres dans le contrôleur de `TTY`, à quelles adresses sont-ils placés dans l'espace d'adressage ?\\Comme ce sont des registres, est-ce que le MIPS peut les utiliser comme opérandes pour ses instructions (comme add, or, etc.) ?\\Dans quel registre faut-il écrire pour envoyer un caractère sur l'écran du terminal (implicitement à la position du curseur) ?\\Que contiennent les registres `TTY_STATUS` et `TTY_READ` ?\\Quelle est l'adresse de `TTY_WRITE` dans l'espace d'adressage ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 10
+* Le composant `TTY` est placé à partir de l'adresse `0xD0200000`.
+* Non, ce sont des registres de périphériques placés dans l'espace d'adressage et donc accessibles par des instructions load/store uniquement.
+* Pour écrire un caractère sur l'écran, il faut écrire le code ASCII du caractère dans le registre `TTY_WRITE`
+* `TTY_STATUS` contient 1 s'il y a au moins un caractère en attente d'être lu, `TTY_READ` contient le code ASCII du caractère tapé au clavier si `TTY_STATUS==1`
+''
+}}}
+1. Le contrôleur de `TTY` peut contrôler de 1 à 4 terminaux. Chaque terminal dispose d'un ensemble de 4 registres (on appelle ça une carte de registres, ou en anglais une ''register map''). Ces ensembles de 4 registres sont placés à des adresses contiguës. S'il y a 2 terminaux (`TTY0` et `TTY1`), à quelle adresse est le registre `TTY_READ` de `TTY1` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 10
+* Si les adresses utilisées par `TTY0` commencent à `0xd0200000` alors celles de `TTY1` commencent à l'adresse `0xd0200010` et donc `TTY_READ` est à l'adresse `0xd0200018`.
+''
+}}}
+1. Que représentent les flèches bleues sur le schéma ? Pourquoi ne vont-elles que dans une seule direction ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 11
+* Ces flèches représentent les requêtes d'accès à la mémoire, c'est-à-dire les ''loads'' et les ''stores'' qui sont émis par le MIPS lors de l'exécution des instructions `lw`, `sw`, etc. Les requêtes sont émises par le MIPS et reçues par les composants mémoires ou périphériques.
+* On ne représente pas les données qui circulent, mais juste les requêtes, pour ne pas alourdir inutilement le schéma. Implicitement, si le MIPS envoie une requête de lecture alors il y aura une donnée qui va revenir, c'est obligatoire, alors on ne la dessine pas, car ce n'est pas intéressant. En revanche, le fait que le MIPS soit le seul composant à émettre des requêtes est une information intéressante.
+''
+}}}
+
+
+== A2. Programmation assembleur
+ 
+
+L'usage du code assembleur est réduit au minimum. Il est utilisé uniquement où c'est indispensable. C'est le cas du code de démarrage. Ce code ne peut pas être écrit en C pour au moins une  raison importante. Le compilateur C suppose la présence d'une pile et d'un registre du processeur contenant le pointeur de pile, or au démarrage les registres sont vides (leur contenu n'est pas significatif). Dans cette partie, nous allons nous intéresser à quelques éléments de l'assembleur qui vous permettront de comprendre le code en TP.
+
+**Questions**
+
+1. Nous savons que l'adresse du premier registre du `TTY` est `0xd0200000` est qu'à cette adresse se trouve le registre `TTY_WRITE` du `TTY0`.\\Écrivez le code permettant d'écrire le code ASCII `'x'` sur le terminal 0. Vous avez droit à tous les registres du MIPS puisqu'à ce stade il n'y pas de conventions sur leur utilisation.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 10\\\\
+Ce qu'il faut bien comprendre, c'est que l'adresse du registre TTY_WRITE est l'adresse d'une __sortie du SoC__, ce n'est pas une mémoire à proprement parler. Il est d'ailleurs interdit de lire à cette adresse. Pour écrire un message à l'écran, il faut écrire tous les caractères du message à cette adresse (0xD0200000). En principe, entre chaque écriture, il faut attendre un peu que le caractère précédent soit parti, parce que le débit du port de sortie matériel (USB par exemple) est beaucoup plus lent que ce que peut faire le processeur. Dans notre cas, c'est un simulateur de SoC et les caractères sont envoyés vers un terminal sans délai. Dans ce cas, il n'est pas nécessaire d'attendre. 
+{{{#!asm
+lui   $4, 0xD020
+ori   $4, $4, 0x0000   // cette instruction ne sert a rien puisqu on ajoute 0, mais je la mets pour le cas general
+ori   $5, $0, 'x'
+sb    $5, 0($4)        // Notez que l immediat 0 devant ($4) n est pas obligatoire mais on s obligera als le mettre
+}}}
+''
+}}} 
+1. Un problème avec le code précédent est que l'adresse du `TTY` est un choix de l'architecte du prototype et s'il décide de placer le `TTY` ailleurs dans l'espace d'adressage, il faudra réécrire le code. Il est préférable d'utiliser une étiquette pour désigner cette adresse : on suppose désormais que l'adresse du premier registre du `TTY`  se nomme `__tty_regs_map`. Le code assembleur ne connait pas l'adresse, mais il ne connaît que le symbole. Ainsi, pour écrire `'x'` sur le terminal 0, nous devons utiliser la macro instruction `la $r, label`. Cette macro-instruction est remplacée lors de l'assemblage du code par une suite composée de deux instructions `lui` et `ori`. Il existe aussi la macro instruction `li` qui demande de charger une valeur sur 32 bits dans un registre. Pour être plus précis, les macro-instructions 
+{{{#!asm
+la $r, label
+li $r, 0x87654321
+}}} 
+ sont remplacées par
+{{{#!asm
+lui $r, label>>16
+ori $r, $r, label & 0xFFFF
+lui $r, 0x8765
+ori $r, $r, 0x4321
+}}}
+ Réécrivez le code de la question précédente en utilisant `la` et `li`
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 19\\\\
+Il suffit de remplacer les instructions `lui` et `ori` par `la` et `li`.
+{{{#!asm
+la    $4, __tty_regs_map
+li    $5, 'x'
+sb    $5, 0($4) 
+}}}
+''
+}}}
+1. En assembleur pour sauter à une adresse de manière inconditionnelle, on utilise les instructions `j label` et `jr $r`. Ces instructions permettent-elles d'effectuer un saut à n'importe quelle adresse ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+La réponse n'est pas dans le cours, mais dans la connaissance du codage des instructions de saut (`j`ump et `b`ranch). Il faut avoir compris que l'instruction `j` et toutes les branchements (`bne`, `beq`, etc.) sont relatives au PC. Il n'est pas possible d'aller n'importe où dans l'espace d'adressage.
+* `j label` malgré sa forme assembleur effectue un saut relativement au `PC` puisque le `label` n'est pas entièrement encodé dans l'instruction binaire (cf. cours sur les sauts). Cette instruction réalise :\\`PC ← (PC & 0xF0000000) | (ZeroExtended(label, 32) << 2)`\\Les 4 bits de poids forts du `PC` sont conservés, le saut est bien relatif au PC\\(`ZeroExtended` désigne ici le fait d'étendre le label sur 32 bits en ajoutant des zéros en tête).\\ Autrement dit, si `j label` est à l'adresse `PC`, l'adresse `label` doit avoir le même chiffre de poids fort (en hexa décimal), c'est-à-dire les mêmes 4 bits de poids fort en binaire). Sinon l'assembleur provoque une erreur lors du codage.
+* A l'inverse, `jr $r` effectue un saut absolu puisque cette instruction réalise `PC ← $r`
+
+Autrement dit, si l’on veut aller exécuter du code n'importe où en mémoire, il faut utiliser `jr`.
+''
+}}}
+1. Vous avez utilisé les directives `.text` et `.data` pour définir les sections où placer les instructions et les variables globales, mais il existe la possibilité de demander la création d'une nouvelle section dans le code objet produit par le compilateur avec la directive `.section name,"flags"` 
+   - `name` est le nom de la nouvelle section.  On met souvent un `.name` (avec un `.`au début) pour montrer que c'est une section et 
+   - `"flags"` informe sur le contenu : `"ax"` pour des instructions, `"ad"` pour des données (ceux que ça intéresse pourront regarder le manuel de l'assembleur [https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_7.html#SEC119 Assembleur/Directives/.section])
+ Écrivez le code assembleur créant la section `".mytext"` et suivi de l'addition des registres `$5` et `$6` dans `$4`
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 19\\\\
+Pour répondre, il faut avoir compris l'explication donnée dans la question. L'intérêt de cette question est de revenir sur la notion de section. Une section est un segment d'adresses ayant un but spécifique. On définit des segments d'adresses pour le code, pour les données (il y a d'ailleurs plusieurs types de sections en fonction du type de données). Ces segments sont placés dans l'espace d'adressage par l'éditeur de liens (`ld`) et la manière dont ils sont placés est définie dans un fichier donné en paramètre de l'éditeur de lien, ce fichier de description de placement est le `ldscript`).
+{{{#!as
+ .section .mytext,"ax"
+ addu $4,$5,$6
+}}} 
+''
+}}}
+1. À quoi sert la directive `.globl label` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 19\\\\
+Ce qu'il faut comprendre, c'est que les comportements du `C` et de l'assembleur sont inversés vis-à-vis des labels. Dans un fichier `.c`, quand on définit un label (une fonction ou variable), ce label est par défaut `extern`, c'est-à-dire qu'il est utilisable dans un autre fichier `.c`. Si on veut que le label ne soit utilisable que dans le fichier dans lequel il est défini, il faut utiliser le mot clé `static` lors de sa déclaration. En assembleur, c'est l'inverse, les labels sont par défaut `static`, c'est-à-dire utilisable uniquement dans le fichier où ils sont définis. Si on veut qu'ils soient utilisables dans les autres fichiers, il faut le dire avec la directive `.globl`.
+* `globl` signifie `glob`al `l`abel. Cette directive permet de dire que le `label` est visible en dehors de son fichier de définition. Ainsi il est utilisable dans les autres fichiers assembleur ou les autres fichier C du programme.
+''
+}}}
+1. Écrivez une séquence de code qui affiche la chaîne de caractère `"Hello"` sur `TTY0`. Ce n'est pas une fonction et vous pouvez utiliser tous les registres que vous voulez. Vous supposez que `__tty_regs_maps` est déjà défini.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Il faut laisser le temps d'écrire ce programme. Si la notion de section est comprise, si les macros `li` et `la` sont comprises, si l'écriture d'une boucle en assembleur est comprise, si l'usage du registre `write` du TTY est compris, alors c'est très facile, et si on donne la correction trop vite alors même ceux qui n'ont pas tout compris vont trouver ça évident.\\
+Si les étudiants ne démarrent pas alors on peut donner la section `.data` et l'initialisation des registres `$4` et `$5`.
+{{{#!asm
+.data
+hello:  .asciiz "Hello"
+.text
+    la      $4, hello                   // $4 <- address of string
+    la      $5, __tty_regs_map          // $5 <- address of tty's registers map 
+
+print:
+    lb      $8, 0($4)                   // get current char
+    sb      $8, 0($5)                   // send the current char to the tty
+    addiu   $4, $4, 1                   // point to the next char
+    bne     $8, $0, print               // check that it is not null, if ok it must be printed
+}}}
+''
+}}} 
+1. En regardant le dessin de l'espace d'adressage du prototype **almo1** (plus haut et sur le slide 7 du cours 9), dites à quelle adresse devra être initialisé le pointeur de pile **pour le kernel**. Rappelez pourquoi c'est indispensable de le définir avant d'appeler une fonction C et écrivez le code qui fait l'initialisation, en supposant que l'adresse du pointeur de pile a pour nom `__kdata_end`.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+On parle ici du pointeur de pile pour le `kernel`, on doit mettre le pointeur de pile dans la section des données du kernel. Ici, il n'y en a qu'une c'est `.kdata`. La pile est mise en haut de cette de cette section aux adresses les plus grandes. Les adresses du bas de la section sont occupées par les données globales du kernel. 
+* La pile va être initialisée juste à la première adresse au-delà de la zone kdata donc\\`__kdata_end = 0x80020000` + `0x003E0000` = `0x80400000`\\Oui, on initialise le pointeur de pile a une adresse qui est en dehors du segment! Ce n'est pas un problème parce que le compilateur C n'écrira jamais à cette adresse, car elle n'est pas dans le contexte de la fonction C. La première chose qu'il fera c'est décrémenter le pointeur de pile pour pour allouer le contexte de la fonction.
+* En effet, la première chose que fait une fonction, c'est décrémenter le pointeur de pile pour écrire `$31`, etc. Il faut donc que le pointeur ait été défini avant d'entrer dans la fonction.
+{{{#!asm
+ la  $29, __kdata_end
+}}}   
+''
+}}}
+
+== A3. Programmation en C
+
+
+Vous savez déjà programmer en C, mais vous allez voir des syntaxes ou des cas d'usage que vous ne connaissez peut-être pas encore. 
+Les questions qui sont posées ici n'ont pas toutes été vues en cours, mais vous connaissez peut-être les réponses, sinon ce sera l'occasion d'apprendre.
+
+**Questions
+
+1. Quels sont les usages du mot clé `static` en C ?  (c'est une directive que l'on donne au compilateur C)
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Le cours 9 n'en parle pas, mais dans le code vous trouverez cette directive un peu partout. Il y a deux usages, on a déjà parlé du premier, mais pas encore du second. 
+1. Déclarer `static` une variable globale ou une fonction en faisant précéder leur définition du mot clé `static` permet de limiter la visibilité de cette variable ou de cette fonction au seul fichier de déclaration. Notez que par défaut les variables et les fonctions du C ne sont pas `static`, il faut le demander explicitement. C'est exactement l'inverse en assembleur où tout label est implicitement  `static` ; il faut demander avec la directive `.globl` de le rendre visible.
+1. Déclarer `static` une variable locale permet de la rendre persistante, c'est-à-dire qu'elle conserve sa valeur entre deux appels. Cette variable locale n'est pas dans le contexte de la fonction (c'est-à-dire qu'elle n'est pas dans la pile parce que le contexte est libéré en sortie de fonction). Une variable locale `static` est en fait allouée comme une variable globale mais son usage est limité à la seule fonction où elle est définie. 
+''
+}}}
+1. Pourquoi déclarer des fonctions ou des variables `extern` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Ça n'ont plus ce n'est pas dit dans le cours mais c'est sensé être connu, sinon c'est qu'il y a des choses à apprendre. Notez que la directive externe est implicite en C et qu'on peut donc ne pas l'écrire. On la met pour la lisibilité du code.
+* Les déclarations `extern` permettent d'informer que le compilateur qu'une variable ou qu'une fonction existe et est définie ailleurs. Le compilateur connaît ainsi le type de la variable ou du prototype des fonctions, il sait donc comment les utiliser. En C, par défaut, les variables et les fonctions doivent être déclarées / leur existence et type doit être connus avant leur utilisation. 
+* Il n'y a pas de déclaration `extern` en assembleur parce que ce n'est pas un langage typé. Pour l'assembleur, un label c'est juste une adresse donc un nombre. 
+''
+}}}
+1. Comment déclarer un tableau de structures en variable globale ? La structure est nommée `test_s`, elle a deux champs `int` nommés `a` et `b`. Le tableau est nommé `tab` et a 2 cases.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Là encore, ce sont des connaissances censées être connues, mais c'est important parce qu'on a besoin de le comprendre pour la déclaration des registres du TTY.
+{{{#!c
+struct test_s {
+  int a;
+  int b;
+};
+struct test_s tab[2];
+}}} 
+''
+}}}
+1. Quelle est la différence entre `#include "file.h"` et `#include <file.h>` ? Quelle option du compilateur C permet de spécifier les répertoires lesquels se trouvent les fichiers include ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 18 et 58\\\\
+Ce sont toujours des connaissances connues en principe, mais comme c'est utilisé dans le code, ce n'est pas inutile d'en parler rapidement.
+* Avec `#include "file.h"`, le préprocesseur recherche le fichier dans le répertoire local.
+* Avec `#include <file.h>`, le préprocesseur recherche le fichier dans les répertoires standards tel que `/usr/include` et dans les répertoires spécifiés par l'option `-I` du préprocesseur. Il peut y avoir plusieurs fois `-I` dans la commande, par exemple `-Idir1 -Idir2 -Idir3`.
+* C'est donc l'option `-I` qui permet de définir les répertoires de recherche.
+''
+}}}
+1. Comment définir une macro-instruction C uniquement si elle n'est pas déjà définie ? Écrivez un exemple.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 9 et 58\\\\
+Cette déclaration est présente à plusieurs endroits dans le code. Elle permet de définir des valeurs de paramètres par défaut, s'ils ne sont pas déjà définis ailleurs, soit plus haut dans le code, ou dans un fichier inclu, ou encore passé en paramètre du compilateur par l'option `-D`.
+* En utilisant, une directive `#ifndef` :
+{{{#!c
+#ifndef MACRO
+#define MACRO
+#endif
+}}} 
+''
+}}}
+1. Comment être certain de ne pas inclure plusieurs fois le même fichier `.h` ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 9 et 58\\\\
+C'est un usage de ce qui a été vu dans la question précédente. C'est utilisé dans tous les fichiers .h (sauf oubli).
+* En utilisant ce que nous venons de voir dans la question précédente : on peut définir une macro instruction différente au début de chaque fichier `.h` (en utilisant le nom du fichier comme nom de macro pour éviter les collisions de nom). On peut alors tester l'existence de cette macro comme condition d'inclusion du fichier. 
+{{{#!c
+————————————————————— debut du fichier filename.h
+#ifndef _FILENAME_H_
+#define _FILENAME_H_
+
+[... contenu du fichier ...]
+
+#endif
+————————————————————— fichier de fichier filename.h
+}}} 
+''
+}}}
+1. Supposons que la structure `tty_s` et le tableau de registres de `TTY` soient définis comme suit. Écrivez une fonction C `int getchar(void)` bloquante qui attend un caractère tapé au clavier sur le `TTY0`. Nous vous rappelons qu'il faut attendre que le registre `TTY_STATUS` soit différent de 0 avant de lire `TTY_READ`. `NTTYS` est un `#define` définit dans le Makefile de compilation avec le nombre de terminaux du SoC (en utilisant l'option `-D` de gcc).
+{{{#!c
+struct tty_s {
+    int write;          // tty's output
+    int status;         // tty's status something to read if not null)
+    int read;           // tty's input
+    int unused;         // unused
+};
+extern volatile struct tty_s __tty_regs_map[NTTYS];
+}}}
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slide 10\\\\
+En principe, cela ne devrait pas poser de difficulté, mais cela nécessite d'avoir compris comment fonctionne le TTY et de savoir écrire une fonction en C. Pour aider, au cas où, on peut donner la description de ce qui est attendu:\\Tant que le registre `status` est à 0 alors attendre, puis lire le registre `read`.\\Notez que cela nécessite de savoir accéder aux champs d'une structure.
+{{{#!c
+int getchar(void) 
+{
+   while (__tty_regs_map[0].status == 0);
+   return __tty_regs_map[0].read;
+}
+}}}
+''
+}}}
+1. Savez-vous à quoi sert le mot clé `volatile` ? Nous n'en avons pas parlé en cours, mais c'est nécessaire pour les adresses des registres de périphérique, une idée ... ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Ce n'est pas dit dans le cours, mais c'est un concept important. Quand le programme doit aller chercher une donnée dans la mémoire puis faire plusieurs calculs dessus, le compilateur optimise en réservant un registre du processeur pour cette variable afin de ne pas être obligé d'aller lire la mémoire à chaque fois. Mais, il y a des cas où ce comportement n'est pas souhaitable (il est même interdit). C'est le cas pour les données qui se trouvent dans les registres de périphériques. Ces données peuvent être changées par le périphérique sans que le processeur le sache, de sorte qu'une valeur lue par le processeur à l'instant `t` n'est plus la même (dans le registre du périphérique) à l'instant `t+1`. Le compilateur ne doit pas optimiser, il doit aller chercher la donnée en mémoire à chaque fois que le programme le demande. 
+* `volatile` permet de dire à `gcc` que la variable en mémoire peut changer à tout moment, elle est volatile. Ainsi quand le programme demande de lire une variable `volatile` le compilateur doit toujours aller la lire en mémoire. Il ne doit jamais chercher à optimiser en utilisant un registre afin de réduire le nombre de lecture mémoire (load). De même, quand le programme écrit dans une variable `volatile`, cela doit toujours provoquer une écriture dans la mémoire (store). 
+* Ainsi, les registres de périphériques doivent toujours être impérativement lus ou écrits à chaque fois que le programme le demande, parce que c'est justement ces lectures et ces écritures qui commandent le périphérique.
+''
+}}}
+
+
+
+== A4. Compilation
+
+
+
+Pour obtenir le programme exécutable, nous allons utiliser :
+* `gcc -o file.o -c file.c`
+  - Appel du compilateur avec l'option `-c` qui demande à `gcc` de faire le préprocessing puis la compilation c pour produire le fichier objet `file.o`
+* `ld -o bin.x -Tkernel.ld files.o ...`
+  - Appel de l'éditeur de liens pour produire l'exécutable `bin.x` en assemblant tous les fichiers objets `.o`, en les plaçant dans l'espace d'adressage et résolvant les liens entre eux. \\Autrement dit, quand un fichier `h.o` utilise une fonction `fg()` ou une variable `vg` définie dans un autre fichier `g.o` (`h` et `g` sont là pour illustrer), alors l'éditeur de liens place dans l'espace d'adressage les sections `.text` et `.data` des fichiers `h.o` et `g.o`, puis il détermine alors quelles sont les adresses de `fg()` et `vg` en mémoire et il complètent les instructions de `h` qui utilisent ces adresses.
+* `objdump -D file.o > file.o.s` ou `objdump -D bin.x > bin.x.s`
+  - Appel du désassembleur qui prend les fichiers binaires (`.o` ou `.x`) pour retrouver le code produit par le compilateur à des fins de debug ou de curiosité.
+
+**Questions**
+
+Le fichier `kernel.ld` décrit l'espace d'adressage et la manière de remplir les sections dans le programme exécutable. Ce fichier est utilisé par l'éditeur de lien. C'est un `ldscript`, c'est-à-dire un [https://www.wikiwand.com/fr/Langage_de_script `script`] pour `ld`.
+{{{#!c
+__tty_regs_map   = 0xd0200000 ; 
+__boot_origin    = 0xbfc00000 ; 
+__boot_length    = 0x00001000 ; 
+__ktext_origin   = 0x80000000 ; 
+__ktext_length   = 0x00020000 ;
+[... question 1 ...]
+__kdata_end      = __kdata_origin + __kdata_length ; 
+
+MEMORY {
+    boot_region  : ORIGIN = __boot_origin,  LENGTH = __boot_length
+    ktext_region : ORIGIN = __ktext_origin, LENGTH = __ktext_length
+[... question 2 ...]
+}
+
+SECTIONS {
+    .boot : {
+        *(.boot)    
+    } > boot_region
+[... question 3 ...]
+    .kdata : {
+        *(.*data*)      
+    } > kdata_region
+}
+}}}
+
+1. Le fichier `kernel.ld` commence par la déclaration des variables donnant des informations sur les adresses et les tailles des régions de mémoire. Ces symboles n'ont pas de type et ils sont visibles de tous les programmes C, il faut juste leur donner un type pour que le compilateur puisse les exploiter, c'est ce que nous avons fait pour `extern volatile struct tty_s __tty_regs_map[NTTYS]`. En regardant dans le dessin de la représentation de l'espace d'adressage, complétez les lignes de déclaration des variables pour la région `kdata_region`
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 23 et 24\\\\
+Pour répondre, il faut savoir interpréter le dessin représentant l'espace d'adressage. Si ça semble difficile, il faut revoir ce qu'est l'espace d'adressage.
+{{{#!c
+__kdata_origin   = 0x80020000 ;
+__kdata_length   = 0x003E0000 ;
+}}}
+''
+}}}
+1. Le fichier contient ensuite la déclaration des régions (dans `MEMORY{...}`) qui seront remplies par l'éditeur de lien avec les sections trouvées dans les fichiers objets selon un ordre décrit dans la partie `SECTIONS{}` du `ldscript`.  Complétez cette partie (la zone `[... question 2 ...]`) pour ajouter les lignes correspondant à la déclaration de la région `kdata_region` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 23 et 24\\\\
+La syntaxe est assez explicite, cela ne devrait pas poser de problème.
+{{{#!c
+kdata_region : ORIGIN = __kdata_origin, LENGTH = __kdata_length
+}}}
+''
+}}}
+1.  Enfin le fichier contient comment sont remplies les régions avec les sections. Complétez les lignes correspondant à la description du remplissage de la région `ktext_region`. Vous devez la remplir avec les sections `.text` issus de tous les fichiers.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 23 et 24\\\\
+Il faut bien comprendre que `.ktext` est une section produite par l'éditeur de liens. C'est ce que l'on appelle une section de sortie. `.text` est une section que l'éditeur de liens trouve dans un fichier objet `.o`, c'est ce que l'on appelle une section d'entrée. Comme il y a plusieurs fichiers objet, on doit dire à l'éditeur de lien de prendre toutes les sections `.text` de tous les fichiers qu'on lui donne. Le `*` devant `(.text)` est une expression régulière permettant de dire à l'éditeur de liens quels fichiers sont concernés, ici avec `*` c'est tous les fichiers. Les expressions régulières sont celles qu'on utilise avec le `shell`.
+{{{#!c
+.ktext : {
+    *(.text)
+} > ktext_region
+}}}
+''
+}}}
+ 
+Nous allons systématiquement utiliser des Makefiles pour la compilation du code, mais aussi pour lancer le simulateur du prototype **almo1**. Pour cette première séance, les Makefiles ne permettent pas de faire des recompilations partielles de fichiers. Les Makefiles sont utilisés pour agréger toutes les actions que nous voulons faire sur les fichiers, c'est-à-dire : compiler, exécuter avec ou sans trace, nettoyer le répertoire. Nous avons recopié partiellement le premier Makefile pour montrer sa forme et poser quelques questions, auxquels vous savez certainement répondre.
+{{{#!make
+# Tools and parameters definitions
+# ------------------------------------------------------------------------------
+NTTY   ?= 2 #                          default number of ttys
+
+CC      = mipsel-unknown-elf-gcc #     compiler
+LD      = mipsel-unknown-elf-ld #      linker
+OD      = mipsel-unknown-elf-objdump # desassembler
+SX      = almo1.x #                    prototype simulator
+
+CFLAGS  = -c #                         stop after compilation, then produce .o
+CFLAGS += -Wall -Werror #              gives almost all C warnings and considers them to be errors
+CFLAGS += -mips32r2 #                  define of MIPS version
+CFLAGS += -std=c99 #                   define of syntax version of C
+CFLAGS += -fno-common #                do not use common sections for non-static vars (only bss)
+CFLAGS += -fno-builtin #               do not use builtin functions of gcc (such as strlen)
+CFLAGS += -fomit-frame-pointer #       only use of stack pointer ($29)
+CFLAGS += -G0 #                        do not use global data pointer ($28)
+CFLAGS += -O3 #                        full optimisation mode of compiler
+CFLAGS += -I. #                        directories where include files like <file.h> are located
+CFLAGS += -DNTTYS=$(NTTY) #            #define NTTYS with the number of ttys in the prototype    
+
+# Rules (here they are used such as simple shell scripts)
+# ------------------------------------------------------------------------------
+help:
+    @echo "\nUsage : make <compil|exec|clean> [NTTY=num]\n"
+    @echo "        compil  : compiles all sources"
+    @echo "        exec    : executes the prototype"
+    @echo "        clean   : clean all compiled files\n"
+
+compil:
+    $(CC) -o hcpua.o $(CFLAGS) hcpua.S
+    @$(OD) -D hcpua.o > hcpua.o.s
+    $(LD) -o kernel.x -T kernel.ld hcpua.o
+    @$(OD) -D kernel.x > kernel.x.s
+
+exec: compil
+    $(SX) -KERNEL kernel.x -NTTYS $(NTTY)
+
+clean:
+    -rm *.o* *.x* *~ *.log.* proc?_term? 2> /dev/null || true
+}}}
+4. Au début du fichier se trouve la déclaration des variables du Makefile, quelle est la différence entre `=`, `?=` et `+=` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Ce n'est pas expliqué dans le cours, mais c'est utilisé dans les `Makefile`s. La syntaxe des `Makefile`s peut-être très complexe (c'est un vieux langage), ici nous ne verrons qu'une partie. La question sur la déclaration des variables optionnelles est intéressante si on fait le parallèle avec ce qu'il faut faire pour avoir le même comportement avec le préprocesseur et ses `#ifndef` (on a une autre méthode encore pour le `shell`.\\A notez que le Makefile `voit` les variables du `shell` comme s'il les avait définies lui même.
+* `=`  fait une affectation simple
+* `?=` fait une affection de la variable si elle n'est pas déjà définie comme variable d'environnement du shell ou dans la ligne de commande de make, par exemple avec `FROM`
+* `+=` concatène la valeur courante à la valeur actuelle, c'est une concaténation de chaîne de caractères. 
+''
+}}}
+1. Où est utilisé `CFLAGS` ? Que fait `-DNTTYS=$(NTTY)` et pourquoi est-ce utile ici ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / Slide 55\\\\
+Le compilateur C peut avoir beaucoup de paramètres. Définir une variable `CFLAGS` permet de les déclarer une fois au début et d'utiliser cette variable plusieurs fois dans le `Makefile`. Si on veut changer un argument, il suffit de le faire une seule fois. Ce genre de choses est nécessaire si on veut faire des `Makefile`s facile à lire et à faire évoluer.
+* La variable `CFLAGS` est utilisée par `gcc`, il y a ici toutes les options indispensables pour compiler mais il en existe beaucoup, ce qui fait des tonnes de combinaison d'options !
+* `-DNTTYS=$(NTTY)` permet de définir et donner une valeur à une macro (ici définition `NTTYS` avec la valeur `$(NNTY)` comme le fait un `#define` dans un fichier C. Cette commande éviter donc d'ouvrir les codes pour les changer.
+''
+}}}
+1. Si on exécute `make` sans cible, que se passe-t-il ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Cours 9 / slides 28 et 29\\\\
+Mettre une règle `help` comme règle par défaut permet de documenter l'usage du `Makefile`, ce qui est plutôt une bonne pratique quand il y a beaucoup de cible et de paramètres. C'est d'autant plus vrai qu'on utilise les Makefiles comme des ensembles de `shell script`.
+* C'est la première cible qui est choisie, donc ici c'est équivalent à `make help`. Cela affiche l'usage pour connaître les cibles disponibles. 
+''
+}}}
+1. à quoi servent  `@` et `-` au début de certaines commandes ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+Ce n'est pas dit en cours, mais comme c'est utilisé, il n'est pas inutile de le savoir. 
+* `@` permet de ne pas afficher la commande avant son exécution. On peut rendre ce comportement systématique en ajoutant la règle `.SILENT:` n'importe où dans le fichier.
+* `-`  permet de ne pas stopper l'exécution des commandes même si elles rendent une erreur, c'est-à-dire une valeur de sortie différente de 0.
+''
+}}}
+
+{{{#!comment
+
+== 
+= B. Travaux pratiques
+
+
+
+Pour les travaux pratiques, vous devez d'abord répondre aux questions, elles ont pour but de vous faire lire le code et revoir les points du cours. Les réponses sont dans le cours ou dans les fichiers sources. Certaines ont déjà été traitées en TD, c'est normal. Ensuite, vous passez aux exercices pratiques.
+
+Vous devez avoir récupérer l'archive tp1.tgz pour pouvoir faire cette partie, si ce n'est pas la cas, retournez lire la section `Récupération du code du TP` en haut de cette page. La variable `shell` `$kO6` doit être définie dans votre environnement si vous avez suivi les consignes de la page [wiki:Howto-TP Config sections 2.2].
+
+Si vous avez bien suivi les étapes de configuration de l'environnement et de récupération du code alors le code se trouve dans `~/kO6/tp1/`, et ouvrez un terminal et allez-y. Dans le répertoire `~/kO6/tp1/` vous avez 5 sous-répertoires et un Makefile. Le fichier `~/kO6/tp1/Makefile` permet de faire le ménage en appelant les Makefiles des sous-répertoires avec la cible `clean`, il est simple, mais c'est un Makefile hiérarchique. Ouvrez-le par curiosité.
+
+
+
+== B1. Premier programme en assembleur dans la seule section de boot
+
+
+
+Nous commençons par un petit programme de quelques lignes en assembleur, placé entièrement dans la région mémoire 
+du boot, qui réalise l'affichage du message "Hello World". C'est un tout tout petit programme, mais pour obtenir 
+l'exécutable, vous devrez utiliser tous les outils de la chaîne de cross-compilation MIPS et 
+pour l'exécuter vous devrez exécuter le simulateur du prototype. C'est simple, mais c'est nouveau pour
+beaucoup d'entre vous
+
+**Objectifs**
+
+- produire un exécutable à partir d'un code en assembleur.
+- savoir comment afficher un caractère sur un terminal.
+- analyse d'une trace d'exécution
+
+**Fichiers**
+
+{{{
+1_hello_boot
+├── hcpua.S      : code dépendant du cpu matériel en assembleur
+├── kernel.ld    : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+└── Makefile     : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+
+
+
+**Questions**
+
+
+1. Dans quel fichier se trouve la description de l'espace d'adressage du MIPS ? Que trouve-t-on dans ce fichier ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- C'est dans le fichier kernel.ld. \\On y trouve:
+  - la définition de variables du ldscript. Ce sont essentiellement des adresses dans l'espace d'adressage, 
+    mais pas seulement, il y a aussi la taille des régions. 
+  - On trouve ensuite la déclaration des régions mémoires.
+  - et enfin la définition des sections de sortie qui seront mises dans le fichier binaire produit et dans quelle région elles sont placées.
+''
+}}}
+1. Dans quel fichier se trouve le code de boot et pourquoi, selon vous, avoir nommé ce fichier ainsi ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le code de boot est dans le fichier `hcpua.S`. Il a a été nommé ainsi parce que c'est du code qui dépend du 
+  hardware, qu'il concerne le cpu et que c'est du code en assembleur. Nous verrons plus tard qu'il y aura un fichier `hcpuc.c`
+''
+}}}
+1. À quelle adresse démarre le MIPS ? Où peut-on le vérifier ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- L'adresse de démarrage est `0xBFC00000`. 
+- On peut le vérifier dans le fichier `kernel.ld`. 
+  Il y a une définition des régions de la mémoire, dont une région commençant à cette adresse-là, et c'est dans 
+  cette région que l'on met le code de boot.
+''
+}}}
+1. Que produit `gcc` quand on utilise l'option `-c` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- L'option `-c` demande à `gcc` de s'arrêter après avoir produit le fichier objet.
+- Il produit donc un fichier au format `.o`
+''
+}}}
+1. Que fait l'éditeur de liens ? Comment est-il invoqué ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- L'éditeur de liens rassemble toutes les sections produites par le compilateur, et donc présentes dans les fichiers objet `.o`, et il les place dans de nouvelles sections, elles-mêmes placées dans les régions de la mémoire, conformément au fichier ldscript (ici `kernel.ld`).
+- L'éditeur de liens est appelé par `gcc` si on n'a pas l'option `-c`ou directement par `ld` (ici `mipsel_unknown_ld`)
+''
+}}}
+1. De quels fichiers a besoin l'éditeur de liens pour fonctionner ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- L'éditeur de liens a besoin des fichiers objets `.o` et du fichier `ldscript` (ici, `kernel.ld`)
+''
+}}}
+1. Dans quelle section se trouve le code de boot pour le compilateur ? ''(la réponse est dans le code assembleur)''
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le code de boot a été mis dans une section `.text`.
+''
+}}}
+1. Dans quelle section se trouve le message "hello" pour le compilateur ? Ce choix est particulier, mais ce message est en lecture seule.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le message est aussi la section `.text`.
+''
+}}}
+1. Dans quelle section se trouve le code de boot dans le code exécutable ? (la réponse est dans `hcpua.S`)
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Dans le programme exécutable, le code de boot est mis dans la section `.boot`.
+''
+}}}
+1. Dans quelle région de la mémoire le code de boot est-il placé ? (la réponse est dans `kernel.ld`)
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le code de boot est placé dans la région `boot_region`
+''
+}}}
+1. Comment connaît-on l'adresse du registre de sortie du contrôleur de terminal `TTY` ? (la réponse est dans `kernel.ld' et sur cette page)
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le fichier `kernel.ld` déclare une variable `__tty_regs_map` initialisée avec l'adresse de
+  où sont placés les registres de contrôles du `TTY`. Le premier registre à l'adresse `__tty_regs_map` 
+  est l'adresse du registre de sortie `TTY_WRITE`. 
+''
+}}}
+1. Le code de boot se contente d'afficher un message, comment sait-on que le message est fini 
+   et que le programme doit s'arrêter ? (ou quel est le caractère de fin de chaîne ?)
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- C'est quand la boucle d'affichage détecte le `0` terminateur de la chaîne de caractères.
+''
+}}}
+1. Pourquoi terminer le programme par un `dead: j dead` ? Notez qu'on ne peut pas encore faire un ''`syscall exit`'' parce qu'il n'y a pas de gestionnaire de syscall et surtout parce `syscall` est une instruction appeler par une application utilisateur, et qu'il n'y en a pas encore.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- If faut arrêter le programme, car il n'y a plus de code, mais on ne sait pas arrêter le processeur, 
+  alors on le faire tourner en rond.
+''
+}}}
+
+**Exercices**
+ 
+- Exécutez le programme en lançant le simulateur avec `make exec`, qu'observez-vous ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- On voit une fenêtre `xterm` qui affiche un message et c'est tout. Dans le terminal de lancement de `make exec`, on voit le compteur de cycles avancer.
+''
+}}}
+- Exécutez le programme en lançant le simulateur avec `make debug`.\\Cela exécute le programme pour une courte durée et cela produit deux fichiers `trace0.s` et `label0.s`.\\`trace0.s` contient la trace des instructions assembleur exécutées par le processeur. \\Ouvrez `trace.0.s` et repérez ce qui est cité ici  
+ - On voit la séquence des instructions exécutées
+ - La première colonne nous informe que les adresses lues sont dans l'espace Kernel
+ - La seconde colonne sont les numéros de cycles
+ - La troisième sont les adresses 
+ - La quatrième le code binaire des instructions
+ - Le reste de la ligne contient l'instruction désassemblée
+ - Lorsque les adresses ont un nom, c'est à dire qu'une étiquette leur a été attribuée, celle-ci est indiquée.
+
+ `label0.s` contient la séquence des appels de fonctions de l'exécutions. C'est en fait un extrait de la trace.\\Ouvrez le fichier `label0.s` et interprétez ce que vous voyez.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+{{{#!asm
+K    12:     <boot>:--------------------------------------------------------------------------------
+K    12:     0xbfc00000 0x3c04bfc0  lui a0,0xbfc0
+K    13:     0xbfc00004 0x24840028  addiu   a0,a0,40
+K    14:     0xbfc00008 0x3c05d020  lui a1,0xd020
+K    15:     0xbfc0000c 0x24a50000  addiu   a1,a1,0
+K    26:     <print>:-------------------------------------------------------------------------------
+K    26:     0xbfc00010 0x80880000  lb  t0,0(a0)
+K    27:     0xbfc00014 0xa0a80000  sb  t0,0(a1)
+K    37:     --> READ  MEMORY @ 0xbfc00028 BE=---1 --> 0x6c6c6548
+K    39:     <-- WRITE MEMORY @ 0xd0200000 BE=---1 <-- 0x48
+}}}
+''
+}}}
+- Modifiez le code de `hcpua.S` afin d'afficher le message "Au revoir\n" après le message "Hello".\\
+  Vous devez avoir deux messages, et pas seulement étendre le premier.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Il faut dupliquer la boucle d'affichage et le message. Il faut juste faire attention aux labels en en créant des nouveaux. On ne peut pas utiliser des fonctions parce qu'il n'y a pas encore de pile d'exécution.
+''
+}}}
+
+
+
+== B2. Saut dans le code du noyau en assembleur
+
+
+
+Dans le deuxième programme, nous restons en assembleur, mais nous avons deux fichiers source : (1) le fichier contenant
+le code de boot et (2) le fichier contenant le code du noyau. Ici, le code du noyau c'est juste une ''fonction'' `kinit()`. Ce n'est pas vraiment une fonction car on n'utilise pas la pile.
+
+**Objectifs**
+
+- Savoir comment le programme de boot fait pour sauter à l'adresse de la routine kinit.
+- Avoir un fichier kernel.ld un peu plus complet.
+ 
+**Fichiers**
+
+{{{
+2_init_asm/
+├── hcpua.S      : code dépendant du cpu matériel en assembleur
+├── kernel.ld    : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+├── kinit.S      : fichier contenant le code de démarrage du noyau, ici c'est une routine kinit.
+└── Makefile     : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+
+**Questions**
+
+1. Regarder dans le fichier `hcpua.S`, dans quelle section est désormais le code de boot ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Il a été placé dans la section de `.boot`
+''
+}}}
+2. Le code de boot ne fait que sauter à l'adresse `kinit` avec l'instruction `jr`, 
+   il n'y a pas de retour, ce n'est donc pas un `jal`. Où est défini `kinit` ? 
+   Comment le code de boot connait-il cette adresse ? 
+   Pourquoi ne pas avoir utilisé `j init` et donc pourquoi passer par un registre ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- `kinit` est défini dans la `kinit.S`. 
+- `hcpua.S` ne connait pas cette adresse, mais grâce au `.globl kinit`, l'éditeur de lien saura compléter `hcpua.o`, dans l'exécutable.
+- Le code de boot est en `0xBFC00000`, `kinit` est en `0x80000000`, ces deux adresses ne partagent pas les 4 bits de poids fort, c'est trop loin pour un simple `j`.
+''
+}}}
+1. Dans `kernel.ld`, que signifie `*(.*data*)` ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- C'est une manière de désigner toutes les sections nommées `.*data*` (avec `*` = n'importe quoi) 
+  présentes dans n'importe quel fichier objets reçu par l'éditeur de liens.
+''
+}}}
+1. Quelle est la valeur de `__kdata_end` ? Pourquoi mettre 2 «`_`» au début des variables du `ldscript` ? ([https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html réponse])
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- `__kdata_end` est l'adresse du premier octet placé juste après la région data.
+- les 2 «`_`» permettent d'éviter les conflits avec les noms des symboles (fonction, variable, type, etc.)
+  présents dans le programme.
+''
+}}}
+
+**Exercices**
+
+- Exécutez le programme sur le simulateur. Est-ce différent de l'étape 1 ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Non, c'est le même comportement.
+''
+}}}
+- Modifiez le code, comme pour l'étape 1, afin d'afficher un second message ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* C'est très semblable, c'est même identique à l'étape 1, l'idée est d'ouvrir le code...
+''
+}}} 
+
+
+
+== B3. Saut dans la fonction kinit() du noyau en langage C
+
+
+
+Dans ce troisième programme, nous faisons la même chose que pour le deuxième mais `kinit()` est désormais écrit en 
+langage C. Cela change peu de choses, sauf une chose importante `kinit()` est une fonction et donc il faut absolument 
+une pile d'exécution.
+
+**Objectifs**
+
+- Savoir comment et où déclarer la pile d'exécution du noyau. 
+- Savoir comment afficher un caractère sur un terminal depuis un programme C.
+
+**Fichiers**
+
+{{{
+3_init_c/
+├── hcpua.S      : code dépendant du cpu matériel en assembleur
+├── kernel.ld    : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+├── kinit.c      : fichier en C contenant le code de démarrage du noyau, ici c'est la fonction kinit().
+└── Makefile     : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+
+**Questions**
+
+1. Quand faut-il initialiser la pile ? Dans quel fichier est-ce ? Quelle est la valeur du pointeur initial ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Il faut initialiser le pointeur avant d'appeler `kinit()`
+- C'est dans le fichier `hcpua.S`
+- `$29` ← `__kdata_end`, c'est-à-dire `0x80400000`
+''
+}}}
+1. Dans quel fichier le mot clé `volatile` est-il utilisé ? Rappeler son rôle.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Il est utilisé dans `kinit.c` pour informer le compilateur que la variable `__tty_regs_map` doit toujours être lue en mémoire et ne peut jamais être "optimisée" dans un registre. Les écritures dans la doivent aussi toujours avoir lieu. Cette variable désigne les registres du contrôleur de terminal. Quand le programme accède en lecture ou écriture à cette variable, il veut accéder au terminal, il faut vraiment qu'il y ait des load/store dans le programme assembleur correspondant au programme source.
+''
+}}}
+
+**Exercices**
+
+- Exécutez le programme sur le simulateur. Est-ce différent de l'étape 1 ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Non, c'est le même comportement :-)
+''
+}}}
+- Ouvrez les fichiers `kinit.o.s` et `kernel.x.s`, le premier fichier est le désassemblage de `kinit.o` et le second est le désassemblage de `kernel.x`. Dans ces fichiers, vous avez plusieurs sections. Les sections `.MIPS.abiflags`, `.reginfo` et `.pdr` ne nous sont pas utiles (elles servent au chargeur d'application, elles contiennent des informations sur le contenu du fichier et cela ne nous intéresse pas).\\Notez l'adresse de `kinit` dans les deux fichiers, sont-ce les mêmes ? Sont-elles dans les mêmes sections ? Expliquez pourquoi.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Dans kinit.o.s, l'adresse de `kinit` est `0` alors que `kernel.x.s` l'adresse est `0x80000000`.
+* Dans kinit.o.s, `kinit` est dans la section `.text` alors que dans `kernel.x.s` `kinit` est dans la section `.ktext`.
+* La raison est que 
+  * dans `kinit.o`, `kinit` n'a pas encore été placé, le compilateur commence toutes ses sections à 0, donc `kinit` est dans la section `.text` et elle commence à 0. 
+  * dans `kernel.x.s` `kinit` est placé et mis dans la section `.ktext` comme le fichier `kernel.ld` le demande.
+''
+}}}
+- Modifiez le code de `kinit.c`, et comme pour l'étape 1, afficher un second message ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Hormis, qu'il s'agit de code C, il n'y a pas de différence de principe, c'est toujours du copier-coller, l'important c'est d'ouvrir le code.
+''
+}}} 
+
+
+
+== B4.  Accès aux registres de contrôle des terminaux `TTY`
+
+
+
+Le prototype de SoC que nous utilisons pour les TP est configurable. Il est possible par exemple de choisir le nombre de terminaux texte (TTY). Par défaut, il y en a un mais, nous pouvons en avoir jusqu'à 4. Nous allons modifier le code du noyau pour s'adapter à cette variabilité. En outre, pour le moment, nous ne faisions qu'écrire sur le terminal, maintenant, nous allons aussi lire le clavier.
+
+**Objectifs**
+
+- Savoir comment compiler un programme C avec du code conditionnel.
+- Savoir comment décrire en C l'ensemble des registres d'un contrôleur de périphérique et y accéder.
+ 
+**Fichiers**
+
+{{{
+4_nttys/
+├── hcpua.S      : code dépendant du cpu matériel en assembleur
+├── kernel.ld    : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+├── kinit.c      : fichier en C contenant le code de démarrage du noyau, ici c'est la fonction kinit().
+└── Makefile     : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+
+**Questions**
+
+1. Dans le fichier `kinit.c`, il est question d'un loopback, à quoi cela sert-il ? 
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Par défaut les caractères tapés au clavier ne sont pas affichés par le matériel. Or, l'utilisateur s'attend au fait que s'il tape sur une touche, celle-ci s'affiche. Comme ce n'est pas le matériel qui le fait c'est au logiciel de le faire. 
+- Le fait que ce soit le logiciel qui fait cette opération de loopback permet de savoir que le programme tourne. Si un caractère s'affiche quand on tape au clavier, c'est qu'un morceau du programme a lu le registre `read` et réécrit cette valeur dans le registre `write`.
+''
+}}}
+1. Dans le fichier `kinit.c`, on trouve `__tty_regs_map[ tty%NTTYS ].write = *s`, expliquez le modulo.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* C'est une sécurité, un peu inutile ici, qui permet de ne pas écrire en dehors de la zone des registres du contrôleur de tty
+''
+}}}
+1. Exécutez le programme sur le simulateur. Qu'observez-vous ? Est-ce que les deux fenêtres ont le même comportement vis-à-vis du clavier ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Deux fenêtres sont apparues avec un message uniquement dans la fenêtre `proc0_term0`.
+- Non. Quand on tape dans la fenêtre `proc0_term0`, les touches tapées s'affichent alors que rien ne se passe dans la fenêtre `proc0_term1`.
+''
+}}}
+
+**Exercices**
+
+- Modifiez le code pour afficher un message sur le second terminal, il y a toujours une attente sur le premier terminal.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- C'est juste deux copier-coller (message et boucle d'affichage).
+''
+}}}
+- Modifiez le code pour que le programme affiche les touches tapées au clavier sur les deux terminaux. C'est-à-dire, ce que vous tapez sur le terminal `proc0_term0` s'affiche sur ce même terminal, et pareil pour `proc0_term1`. L'idée est de ne plus faire d'attente bloquante sur le registre `TTY_STATUS` de chaque terminal. Pour que cela soit plus amusant, changez la casse (minuscule ←→ majuscule) sur le terminal `proc1_term1` (si vous tapez `bonjour 123`, il affiche `BONJOUR 123` et inversement.
+{{{#!protected ------------------------------------------------------------------------------------
+''
+{{{#!c
+void kinit (void)
+{
+    char *s;
+    char c;
+
+    for (s = hello_0; *s; s++) {                // for all char in hello string
+        __tty_regs_map[ 0%NTTYS ].write = *s;   // write it to the tty output register
+    }
+
+    for (s = hello_1; *s; s++) {                // for all char in hello string
+        __tty_regs_map[ 1%NTTYS ].write = *s;   // write it to the tty output register
+    }
+
+    while (1) {
+
+        if (__tty_regs_map[0].status != 0) {    // wait for a char typed on keyboard 0
+            c = __tty_regs_map[0].read;         // read the char
+            __tty_regs_map[0].write = c;        // and print it (that is a software loopback)
+        }
+        if (__tty_regs_map[1].status != 0) {    // wait for a char typed on keyboard 1
+            c = __tty_regs_map[1].read;         // read the char
+            if ((c >= 'a') && (c <= 'z'))
+                c += 'A' - 'a';
+            else if ((c >= 'A') && (c <= 'Z'))
+                c += 'a' - 'A';
+            __tty_regs_map[1].write = c;        // and print it (that is a software loopback)
+        }
+
+    }
+
+    while (1); 
+}}}
+''
+}}}
+
+
+
+== B5. Premier petit pilote pour le terminal
+
+
+
+Dans l'étape précédente, nous accédons aux registres de périphérique directement dans la fonction `kinit()`, ce n'est pas très simple. C'est pourquoi nous allons ajouter un niveau d'abstraction qui représente un début de pilote de périphérique (device driver). Ce pilote, même tout petit constitue une couche logicielle avec une API.
+
+**Objectifs**
+
+- Savoir comment créer un début de pilote pour le terminal `TTY`.
+- Savoir comment décrire une API en C
+- Savoir appeler une fonction en assembleur depuis le C
+ 
+**Fichiers**
+
+{{{
+5_driver/
+├── harch.c      : code dépendant de l'architecture du SoC, pour le moment c'est juste le pilote du TTY
+├── harch.h      : API du code dépendant de l'architecture
+├── hcpu.h       : prototype de la fonction clock()
+├── hcpua.S      : code dépendant du cpu matériel en assembleur
+├── kernel.ld    : ldscript décrivant l'espace d'adressage pour l'éditeur de lien
+├── kinit.c      : fichier en C contenant le code de démarrage du noyau, ici c'est la fonction kinit().
+└── Makefile     : description des actions possibles sur le code : compilation, exécution, nettoyage, etc.
+}}}
+   
+**Questions**
+
+1. Le code du driver du TTY est dans le fichier `harch.c` et les prototypes sont dans `harch.h`. Si vous ouvrez `harch.h` vous allez voir que seuls les prototypes des fonctions `tty_gets()` et `tty_puts()` sont présents. La structure décrivant la carte des registres du `TTY` est déclarée dans le `.c`. Pourquoi avoir fait ainsi ?
+{{{#!protected ------------------------------------------------------------------------------------
+''
+- Le noyau n'a pas besoin de savoir comment sont organisés les registres dans le TTY. Il a juste besoin de savoir comment écrire ou lire un message. Plus c'est cloisonné, moins il y a de risque de problèmes. En outre, cela simplifie un hypothétique portage sur une autre architecture.
+''
+}}}
+1. Le MIPS dispose d'un compteur de cycles internes. Ce compteur est dans un banc de registres accessibles uniquement quand le processeur fonctionne en mode `kernel`. Nous verrons ça au prochain cours, mais en attendant nous allons quand même exploiter ce compteur. Pourquoi avoir mis la fonction dans `hcpua.S` ? Rappeler, pourquoi avoir mis `.globl clock`
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* La fonction qui lit ce registre (Attention ce `$9` ne désigne pas un registre GPR du processeur !) est nécessairement en assembleur car elle utilise des instructions particulières et dépend du matériel, elle est donc mise dans `hcpua.S`. 
+* `.globl clock` permet de faire en sorte que la fonction soit visible par les autres fichiers C.
+''
+}}}
+1. Compilez et exécutez le code avec `make exec`. Observez. Ensuite ouvrez le fichier `kernel.x.s` et regardez où a été placée la fonction `clock()`.\\Est-ce un problème si `kinit()` n'est plus au début du segment `ktext` ? Posez-vous la question de qui a besoin de connaître l'adresse de `kinit()`
+{{{#!protected ------------------------------------------------------------------------------------
+''
+* Non, ce n'est pas un problème puisque ça fonctionne. Le code de boot a besoin de l'adresse de `kinit()` mais on l'obtient avec la macro `la` - c'est l'éditeur de lien qui fera en sorte que dans les codes binaire l'adresse de `kinit()` mise dans le registre `$26` soit la bonne.
+''
+}}}
+
+**Exercices**
+
+- Afin de vous ''détendre un peu'', vous allez créer un petit jeu `guess`
+  - `guess` tire un nombre entre '0' et '9' et vous devez le deviner en faisant des propositions.\\`guess` vous dit si c'est trop grand ou trop petit. Ce programme ne va révolutionner votre vie de programmeur(se), mais bon, c'est probablement le premier programme que vous allez écrire et faire tourner sur une machine sans système d'exploitation.
+ __Étapes__
+  - Vous créez deux fichiers `guess.c` et `guess.h`. 
+    - `guess.c` contient le jeu il y au moins une fonction `guess()` 
+    - `guess.h` contient les déclarations externes de `guess.c`
+  - `kinit()` doit lancer `guess()`
+  - `guess()` 
+     - vous demande de taper une touche pour démarrer le jeu.
+     - effectue un tirage d'un nombre en utilisant la fonction `clock()` et ne gardant que le chiffre de poids faible (ce n'est pas aléatoire, mais c'est mieux que rien)
+     - exécute en boucle jusqu'à réussite 
+       - demande d'un chiffre
+       - comparaison avec le tirage et affichage des messages `"trop grand"`, `"trop petit"` ou `"gagné"`
+  - Vous devrez modifier le Makefile puisque vous avez un fichier à compiler en plus.
+  - Si c'est trop facile, vous pouvez complexifier en utilisant des nombres à 2 chiffres ou plus. 
+{{{#!protected
+[htdocs:files/6_guess.tgz 6_guess.tgz à décompresser dans tp1]\\\\
+**kinit.h**
+{{{#!c
+#include <harch.h>
+#include <guess.h>
+
+char hello[] = "Hello World!\n\n";
+char end[] = "\nend!\n";
+
+void kinit (void)
+{
+    tty_puts (0, hello);         // print hello string
+    guess();
+    tty_puts (0, end);           // print end string on terminal 0
+    while (1);                   // infinite loop
+}
+}}}
+**guess.h**
+{{{#!c
+#ifndef _GUESS_H_
+#define _GUESS_H_
+
+extern void guess (void);
+
+#endif
+}}}
+**guess.c**
+{{{#!c
+#include <guess.h>
+#include <harch.h>
+#include <hcpu.h>
+
+void guess (void)
+{
+    char c;
+    int num;
+    int random;
+
+    do {
+        random = clock() % 10;  // only one digit
+        do {
+            do {
+                tty_puts(0,"Donnez un nombre : ");
+                c = tty_getc(0);
+            } while ( (c < '0') && (c > '9') );
+            num = c - '0';
+
+            if (num < random)
+                tty_puts(0," -> trop petit\n");
+            else if (num > random)
+                tty_puts(0," -> trop grand\n");
+
+        } while (random != num);
+
+        tty_puts(0,"\nGagné\n");
+        tty_puts(0,"\nOn recommence [Y]/N ? ");
+        c = tty_getc(0);
+        tty_puts(0,"\n\n");
+
+    } while (c != 'N');
+}
+}}}
+}}}