| 200 | | Un vrai système d'exploitation tel que LINUX ou MutekH permet de créer dynamiquement de nouvelles tâches (i.e. de nouveaux programmes utilisateurs) alors que la machine est déjà démarrée (mécanisme ''pthread_create()'' pour les threads POSIX, ou mécanisme fork/exec pour les processus UNIX). |
| 201 | | Le GIET n'étant pas un vrai système d'exploitation, ne supporte pas la création ou la destruction dynamique de tâches : Les tâches doivent être créées une fois pour toute au démarrage de la machine, c'est à dire dans le code de boot. |
| 202 | | |
| 203 | | Bien que le GIET supporte le fonctionnement multi-tâches (un seul processeur exécute plusieurs tâches par multiplexage temporel), on va utiliser ici un mécanisme plus simple: Tous les processeurs exécutent le même ''code de boot, |
| 204 | | mais l'exécution de ce code dépend de l'index du processeur. |
| 205 | | L'index du processeur étant stockée dans un registre système (registre $15 pour le processeur MIPS32), sa valeur peut être testée par le logiciel. cette valeur est initialisée par le constructeur, ce qui modélise une valeur ''cablée'' lors de la fabrication de la puce. |
| | 203 | Un vrai système d'exploitation tel que LINUX ou MutekH permet de créer dynamiquement de nouvelles tâches (i.e. de nouveaux programmes utilisateurs) alors que la machine est déjà démarrée (mécanisme ''pthread_create()'' pour les threads POSIX, ou mécanisme fork/exec pour les processus UNIX). Le GIET n'étant pas un vrai système d'exploitation, ne supporte pas la création ou la destruction dynamique de tâches : Les tâches doivent être créées une fois pour toute au démarrage de la machine, c'est à dire dans le code de boot. |
| | 204 | |
| | 205 | Bien que le GIET supporte le fonctionnement multi-tâches (un seul processeur exécute plusieurs tâches par multiplexage temporel), on va utiliser ici un mécanisme plus simple où chaque processeur n'exécute qu'une seule tâche. Le mot tâche désigne ici un programme utilisateur particulier. |
| | 206 | |
| | 207 | Le mécanisme est le suivant : |
| | 208 | * Tous les processeurs exécutent le même ''code de boot, mais l'exécution de ce code dépend de l'index du processeur. L'index du processeur (''proc_id'') étant stocké dans un registre système (registre $15 pour le processeur MIPS32), sa valeur peut être testée par le logiciel. Cette valeur est initialisée par le constructeur, ce qui modélise une valeur ''cablée'' lors de la fabrication de la puce. |
| | 209 | * Les tâches s'exécutant en parallèle, chaque tâche (et donc chaque processeur) doit disposer de sa propre pile d'exécution. On définit un seul segment pour les différentes piles d'exécution, mais les ponteurs de pile des différents processeurs doivent être initialisés à des valeurs différentes en fonction du ''proc_id''. |
| | 210 | * Chaque tâche correspondant à un programme utilisateur différent, les points d'entrée de chaque tache (registre EPC dans le cas du MIPS32) doivent être initialisées à des valeurs différentes (main_0, main_1, main_2, etc...) en fonction du ''proc_id''. |
| | 211 | |
| | 212 | '''Question''' : Modifiez le fichier '''reset.s''' pour initialiser le pointeur de pile ($29 dans le cas du MIPS32) à une valeur dépendant du ''proc_id''. Chaque tâche disposera d'une pile de 64 Koctets. Quelle doit être la taille minimale du segment de pile défini dans la table des segments de la top-cell? |
| | 213 | |
| | 214 | '''Question''' : Modifiez le fichier '''reset.s''' pour initialiser le point d'entrée (registre EPC dans le cas du MIPS32) à une valeur dépendant du ''proc_id''. On pourra définir une table de sauts indexé par le proc_id et contenant les adresses ''main_0'' à ''main_7''. |
| | 215 | |
| | 216 | '''Question''' : Modifiez le fichier '''Makefile''' du répertoire '''soft''' pour que soient compilés le fichier '''teset.s''' ainsi modifié, et les deux programmes '''main_1.c''' et '''main_1.c''' de la section 4. |
| | 217 | |
| | 218 | '''Question''' : Lancez l'exécution sur le simulateur '''simulator_multi.x'''. |
