Changes between Version 69 and Version 70 of Archi-1-TP9
- Timestamp:
- Dec 4, 2020, 10:52:16 AM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archi-1-TP9
v69 v70 9 9 10 10 Cette page décrit la séance complète : TD et TME. 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. 11 La partie pratique est découpé en 5 étapes. Pour chaque étape, nous donnons une brève description, suivie d'une liste des objectifs principaux et d'une liste des fichiers présents. Un bref commentaire est ajouté pour les fichiers. Vous avez une liste de questions simple et l'exercice de codage.11 La partie pratique est découpée en 5 étapes. Pour chaque étape, nous donnons une brève description, suivie d'une liste des objectifs principaux et d'une liste des fichiers présents. Un bref commentaire est ajouté pour les fichiers. Vous avez une liste de questions simple et l'exercice de codage. 12 12 13 13 Avant de faire cette séance, vous devez avoir lu les documents suivants : … … 25 25 26 26 * Vous devez commencer par récupérer [htdocs:files/tp1.tgz l'archive code du tp1] 27 * Assurez 27 * Assurez-vous que vous avez déjà sourcé le fichier `Source-me.sh` (il doit être dans votre `.bashrc`). 28 28 * Placez cette archive dans le répertoire AS5 et décompressez-la avec **`tar xvzf tp1.tgz`** 29 29 * Après décompression, avec la commande **`tree -L 1 tp1`**, vous devriez obtenir ceci: … … 181 181 {{{#!protected ------------------------------------------------------------------------------------ 182 182 ''''''''''''''' 183 * `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 d'autres programme assembleur ou d'autres programmes C.183 * `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 d'autres programmes assembleur ou d'autres programmes C. 184 184 ''''''''''''''' 185 185 }}} … … 224 224 {{{#!protected ------------------------------------------------------------------------------------ 225 225 ''''''''''''''' 226 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. Noter que par défaut les variableet les fonctions du C ne sont pas `static`, il faut le demander explicitement. C'est exactement l'inverse en assembleur où tous les labels sont static et il faut demander avec `.globl` pour le rendre visible.226 1. Déclarer `static` une variable globale ou une fonction en faisant précéder leur définition du mot clé `static` permets 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ù tous les labels sont static et il faut demander avec `.globl` pour le rendre visible. 227 227 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 (celui-ci est dans la pile et il est libéré en sortie de fonction). Une variable locale statique est en fait une variable globale dont l'usage est limité à la seule fonction où elle est définie. 228 228 ''''''''''''''' … … 316 316 317 317 318 Pour obtenir le programme exécutable nous allons utiliser :318 Pour obtenir le programme exécutable, nous allons utiliser : 319 319 * `gcc -o file.o -c file.c` 320 320 - 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` … … 324 324 - Appel du désassembleur prend les fichiers binaires (`.o` ou `.x`) pour retrouver le code produit par le compilateur à des fins de debug ou de curiosité. 325 325 326 **Questions** 327 1. Le fichier `kernel.ld` décrit l'espace d'adressage et la manière de remplir les sections dans le programme exécutable. 326 Le fichier `kernel.ld` décrit l'espace d'adressage et la manière de remplir les sections dans le programme exécutable. 328 327 {{{#!c 329 328 __tty_regs_map = 0xd0200000 ; … … 345 344 *(.boot) 346 345 } > boot_region 347 [... question 2...]346 [... question 3 ...] 348 347 .kdata : { 349 348 *(.*data*) … … 351 350 } 352 351 }}} 353 1. ? 354 {{{#!protected ------------------------------------------------------------------------------------ 355 ''''''''''''''' 356 * 357 ''''''''''''''' 358 }}} 359 - Le fichier 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 le compilateur puisse les exploiter, c'est ce que nous avons fait pour `extern volatile struct tty_s __tty_regs_map[NTTYS]` 360 - Le fichier contient ensuite la déclaration des régions qui vont être remplies par les sections trouvées dans les fichiers objets. 361 - Enfin le fichier contient comment sont remplies les régions avec les sections 362 363 Les variables déclarées externes ne sont évidemment pas mises dans la section `.data` du fichier objet en sortie et les appels aux fonctions sont codés par des `jal ?` puisque le code des fonctions n'est pas là. Ce sera ré 364 365 366 367 368 = Travaux Pratiques 352 353 **Questions** 354 355 1. Le fichier 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 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` 356 {{{#!protected ------------------------------------------------------------------------------------ 357 ''''''''''''''' 358 {{{#!c 359 __kdata_origin = 0x80020000 ; 360 __kdata_length = 0x003E0000 ; 361 }}} 362 ''''''''''''''' 363 }}} 364 1. Le fichier contient ensuite la déclaration des régions qui vont être remplies par les sections trouvées dans les fichiers objets. Complétez les lignes propres à la déclaration de la région `kdata_region`. 365 {{{#!protected ------------------------------------------------------------------------------------ 366 ''''''''''''''' 367 {{{#!c 368 kdata_region : ORIGIN = __kdata_origin, LENGTH = __kdata_length 369 }}} 370 ''''''''''''''' 371 }}} 372 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. 373 {{{#!protected ------------------------------------------------------------------------------------ 374 ''''''''''''''' 375 {{{#!c 376 .ktext : { 377 *(.text) 378 } > ktext_region 379 }}} 380 ''''''''''''''' 381 }}} 382 383 384 385 386 = Travaux pratiques 369 387 370 388 … … 403 421 404 422 - **Questions**\\ 405 ''Les réponse sont dans le cours ou dans les fichiers sources''\\\\423 ''Les réponses sont dans le cours ou dans les fichiers sources''\\\\ 406 424 - Dans quel fichier se trouve la description de l'espace d'adressage du MIPS ? Que trouve-t-on dans ce fichier ? 407 425 {{{#!protected ------------------------------------------------------------------------------------