Changes between Version 68 and Version 69 of Archi-1-TP9

Timestamp:

Dec 4, 2020, 9:26:00 AM (4 years ago)

Author:

franck

Comment:

--

Archi-1-TP9

@@ -282 +282 @@
 }}}
 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`.
-
 {{{#!c
 struct tty_s {
@@ -303 +302 @@
 '''''''''''''''
 }}}
-
-
-== A3. Chaîne de compilation
+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 ------------------------------------------------------------------------------------
+'''''''''''''''
+* `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 directement 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.
+'''''''''''''''
+}}}
+
+
+
+== A3. 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 -Tldscript files.o ...`
+  - 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 lien 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 (quand un `.o` utilise une fonction ou une variable définie dans un autre `.o`). 
-$ objdump
-1. Le fichier « ldscript » décrit l'espace d'adressage et la manière de remplir les sections dans le programme exectutable. Quelle étape dans la chaîne de compilation a besoin de cette description ?
- Les variables déclarées externes ne sont évidemment pas mise dans la section `.data` du fichier objet en sortie et les appel au fonction sont codés par des `jal ?` puisque le code des fonctions n'est pas là. Ce sera ré
+* `objdump -D file.o > file.o.s` ou `objdump -D bin.x > bin.x.s`
+  - 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é.
+
+**Questions**
+1. Le fichier `kernel.ld` décrit l'espace d'adressage et la manière de remplir les sections dans le programme exécutable.
+{{{#!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 2 ...]
+    .kdata : {
+        *(.*data*)      
+    } > kdata_region
+}
+}}}
+1.  ?
+{{{#!protected ------------------------------------------------------------------------------------
+'''''''''''''''
+* 
+'''''''''''''''
+}}}
+ - 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]` 
+ - Le fichier contient ensuite la déclaration des régions qui vont être remplies par les sections trouvées dans les fichiers objets.
+ - Enfin le fichier contient comment sont remplies les régions avec les sections
+ 
+ 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é