TP7 : TSAR & ALMOS-MKH

1. Objectifs

Le but de ce TP est de présenter le simulateur de l'architecture manycore TSAR, ainsi que le système d'exploitation ALMOS-MKH. Pour cela vous allez dans un premier temps générer le simulateur de l'architecture matérielle. Puis vous allez générer le code binaire de l'OS, du bootloader, et du préloader. Finalement vous allez exécuter une petite application sur cette plate-forme.

Avertissement : On cherche principalement dans ce TP à vous inciter à lire la documentation disponible sur les serveurs WEB des projets ​TSAR et ​ALMOS-MKH, en vous fournissant les pointeurs nécessaires. La compilation de l'OS et la génération du simulateur ne demandent que quelques minutes. Le lancement du simulateur et les expérimentations peuvent se faire en 15 minutes. Prenez donc le temps de lire soigneusement la documentation...

Les codes sources, pour le simulateur de l'architecture matérielle, pour le code système, et pour le code applicatif vous sont fournis dans un fichier tar.

Vous travaillerez dans le répertoire local de votre poste de travail /dsk/l1/misc, qui possède une grosse capacité de stockage. Cependant, l'utilisation du répertoire /dsk/l1/misc impose que vous fassiez tous les TPs sur la même machine. Ce répertoire n'est pas sauvegardé, et peut donc être perdu. Il est fortement conseillé de sauvegarder vos fichiers sources en fin de session sur votre compte personnel.

Commencez par copier dans le répertoire /dsk/l1/misc de votre poste de travail le fichier d'archive almos-mkh_tsar_fw.tjf qui se trouve sur la machine dvorak:

cd /dsk/l1/misc
scp gallus:/dsk/l1/misc/almos-mkh_tsar_fw.tjf .

La décompression de ce fichier doit créer un répertoire almos-mkh_tsar_fw, qui contient lui-même les deux répertoires almos_mkh et tsar, ainsi que le fichier env.sh qui permet d'initialiser les variables d'environnement.

tar xjf almos-mkh_tsar_fw.tjf

Il est important que la décompression se fasse dans le répertoire /dsk/l1/misc parce que les fichiers de configuration d'ALMOS-MKH font cette hypothèse. Après décompression, l'ensemble des fichiers occupent environ 250Moctets.

Le répertoire almos-mkh est une copie du dépôt SVN contenant le code source (C) du système d'exploitation almos-mkh. Il contient principalement les répertoires suivants:

• /almos-mkh/kernel : code du noyau indépendant de l'architecture cible.
• /almos-mkh/hal : code du noyau dépendant de l'architecture cible.
• /almos-mkh/boot : code des bootloaders pour les différentes architectures cibles.
• /almos-mkh/libs : bibliothèques de fonctions utilisées pour accéder aux services système.
• /almos-mkh/user : quelques codes applicatifs, dont init, et un petit shell appelé ksh.

Le répertoire tsar est une copie du dépôt SVN contenant le code source (SystemC) des différents simulateurs de l'architecture tsar. Le simulateur que vous utiliserez dans ce TP et dans les suivants est dans le répertoire /tsar/platforms/tsar_generic_iob.

Vous allez devoir renommer le répertoire en remplaçant _fw par vos initiales _xx. Je suppose que vos initiales sont moi Lancez script env.sh qui permet d'initialiser les variables d'environnement requis par les outils de compilation.

mv /dsk/l1/misc/almos-mkh_tsar_fw /dsk/l1/misc/almos-mkh_tsar_moi
cd /dsk/l1/misc/almos-mkh_tsar_moi

Vous allez devoir modifier les fichiers suivants en remplaçant fw par moi.

./env.sh
./almos-mkh/params-hard.mk
./almos-mkh/params-soft.mk
./almos-mkh/Makefile

Esuite, vous devez sourcer la configuration de l'environnement :

source env.sh

Vous pouvez mettre ce source à la fin de votre fichier .bashrc, afin de ne pas avoir à exécuter ce script pour chaque shell. Toutefois, juste après avoir modifié le .bashrc, vous devez forcer sa lecture.

echo "source /dsk/l1/misc/almos-mkh_tsar_moi/env.sh" >> ~/.bashrc
source ~/.bashrc

2. Architecture manycore TSAR

Comme l'architecture multicluster du TP5, l'architecture TSAR est une architecture clusterisée. Chaque cluster[i] contient

• entre 1 et 4 coeurs MIPS32 avec leur cache L1,
• un cache L2 représentant le segment mémoire physique accessible dans le cluster[i],
• un contrôleur d'interruptions local contenant également des timers,
• un contrôleur DMA utilisé par l'OS pour accélérer les mouvements de données de mémoire à mémoire,

Les 6 principales différences par rapport à l'architecture clusterisée du TP5 sont les suivantes:

2.1 Espace d'adressage 40 bits

L'architecture TSAR utilise des processeurs 32bits pour minimiser la consommation énergétique. Chaque application possède donc un espace virtuel limité à 4 Goctets (adresses virtuelles sur 32 bits). Mais l'espace d'adressage physique a une taille de 1 Tera-octet (adresses physiques sur 40 bits). Les 8 bits de poids fort de l'adresse définissent les coordonnées du cluster cible de la transaction. Le segment de mémoire physique accessible dans un cluster ne peut donc pas avoir une longueur supérieure à 4 Goctets.

Pour effectuer les traductions (adresses virtuelles 32 bits => adresses physiques 40 bits) le contrôleur de cache L1 contient une MMU gérant une mémoire virtuelle paginée. Cette MMU supporte deux types de pages (4 Koctets, et 2 Moctets). Les spécifications détaillées de cette MMU peuvent être trouvées ​ici.

En plus de ce mécanisme de traduction paginé, la MMU de TSAR possède un second mécanisme de traduction d'adresse, qui ne concerne que les adresses de données: Lorsque la MMU DATA est désactivée toutes les adresses virtuelles sur 32 bits sont étendues a 40 bits par concaténation d'un numéro de cluster sur 8 bits, stocké dans un registre protégé de la MMU. Ce mécanisme - exclusivement réservé au système d'exploitation - permet à n'importe quel coeur d'accéder en lecture ou en écriture à n'importe quelle adresse de la machine.

2.3 Cohérence des caches

Le contrôleur de cache L1et le contrôleur de cache L2 implémentent le protocole DHCCP présenté en cours, et permettant au matériel de garantir la cohérence entre les caches L1 et les caches L2 sans intervention du logiciel. La cohérence des caches TLB de la MMU est également assurée par le protocole DHCCP. Les spécifications détaillées peuvent être trouvées ​ici.

2.4 Micro-réseau

L'architecture de communication entre les caches L1 et les caches L2 est un NoC comportant une partie globale pour la communication inter-clusters, et une partie locale pour la communication intra-cluster. L'interconnect global est constitué de 5 réseaux DSPIN totalement indépendants, ayant chacun une topologie de grille 2D. Chaque interconnect local est constitué - dans chaque cluster - de 5 crossbars totalement indépendants. Les spécifications détaillées peuvent être trouvées ​ici.

2.5 Opérations atomiques

Le contrôleur de cache L1 et le contrôleur de cache L2 implémentent le mécanisme de lecture-puis-écriture atomique (LL/SC) sans snoop présenté en cours. Les spécifications détaillées de ce mécanisme peuvent être trouvées ​ici.

2.6 Périphériques déportés

Les principaux contrôleurs de périphériques (contrôleur disque / contrôleur réseau / contrôleur TTY, contrôleur graphique, ROM de boot) ne sont pas distribués dans les clusters, mais sont connectés à un bus externe auquel on accède par un bridge (passerelle appelée IOB, pour Input Output Bridge) localisé dans le cluster de coordonnées(x_size-1,y_size-1).

Le simulateur de cette architecture TSAR est une application logicielle écrite en langage SystemC, s'exécutant sur une machine Linux, et appelée tsar.x. Le code source décrivant cette architecture est accessible dans le fichier `tsar/top.cpp'.

3. Système d'exploitation almos-mkh

Almos-mkh est un système d'exploitation généraliste de type UNIX (c'est-à-dire respectant la norme POSIX), qui vise à analyser - et si possible à résoudre - les problèmes de passage à l'échelle posés par les architectures manycores à espace d'adressage partagé de type NUMA. Le sigle ALMOS-MKH signifie Advanced Locality Management Operating System - Multi Kernel Hybrid. L'objectif principal est de favoriser la localité des accès mémoire par une gestion intelligente du placement, et surtout d'éliminer les goulots d'étranglement, par une politique de réplication et/ou de distribution des ressources et des services. Ceci explique l'approche multi-kernel rappelée ci-dessous. Pour permettre de s'adapter à différents types de systèmes de fichier, almos-mkh, comme la plupart des systèmes UNIX, accède aux fichiers stockés sur disque à travers une API de type VFS (Virtual File System). Actuellement almos-mkh supporte trois systèmes de fichiers: RAMFS, SYFS, et FAT32. Pour ce TP et les suivants, on supposera que le disque externe est formaté au format FAT32.

On rappelle que dans un système d'exploitation multi-kernel, il existe une instance du système dans chaque cluster. Chaque instance du noyau est autonome, et dispose de ses propres structures de données, qui lui permettent de gérer les ressources matérielles locales au cluster, et de répondre aux requêtes des applications qui s'exécutent dans le cluster. Les structures de données locales à un cluster[i] sont par exemple l'allocateur chargé d'allouer la mémoire physique disponible dans le cluster[i] (au plus 4 Goctets par cluster dans l'architecture TSAR), ou les ordonnanceurs des coeur[i][j] contenus dans le cluster[i] On rappelle qu'il y a un ordonnanceur par coeur, et que l'indice local j du coeur est compris entre 1 et 4 dans le cas de l'architecture TSAR.

Concernant les périphériques, almos-mkh définit, pour chaque périphérique (et pour les périphériques multi-canaux, pour chaque canal du périphérique) une abstraction appelée device, qui permet de masquer les détails d'implémentation de chaque périphérique dans un driver spécifique. Cette abstraction facilite l'installation de nouveaux périphériques en évitant une intervention profonde dans le code du noyau. Il existe donc une structure de données device pour chaque canal de chaque périphérique, interne ou externe, avec des fonctions d'accès spécifique à chaque type de device. Pour les périphériques internes à un cluster[i], ces structures devices sont évidemment locales au cluster[i]. Pour les périphériques externes, ceux-ci sont évidemment partagés par toutes les instances de l'OS, puisque chaque périphérique peut être utilisé par n'importe quelle thread s'exécutant sun'importe quel coeur de n'importe quel cluster. Pour répartir la charge, et éviter de créer des points de contention, almos-mkh répartit équitablement ces structures devices dans tous les clusters, et chaque instance du noyau se retrouve propriétaire d'un petit nombre de devices externes.

En plus des ressources locales à un cluster, almos-mkh a également besoin de structures de données globales. Un exemple est la représentation en mémoire du système de fichier VFS, composé de l' arbre des inodes, et des caches de fichiers gérés par l'OS (un cache par fichier). Cette structure est trop volumineuse pour être stockée dans un seul cluster, au risque de constituer un goulot d'étranglement. C'est donc une structure distribuée sur tous les clusters de l'architecture, qui peut être parcourue de façon concurrente par toutes les instances de l'OS.

Bien que chaque instance de l'OS dispose de ses propres structures de données locales, les différentes instances de l'OS ont besoin de pouvoir échanger de l'information pour coopérer entre elles. Ceci nécessite que l'OS d'un cluster[i] puisse lire ou écrire dans la mémoire d'un autre cluster[j]. Par ailleurs, pour accéder aux structures distribuées - telle que le VFS - un coeur d'un cluster[i] doit pouvoir écrire ou lire dans la mémoire d'un cluster[j] distant. Tous ces accès distants utilisent une API de fonctions spécialisées, définies dans le fichier ​almos-mkh/hal/generic/hal_remote.h. L'implémentation de cette API dépend de l'architecture cible. Dans le cas de TSAR, vous trouverez l'implémentation dans le fichier ​almos-mkh/hal/tsar_mips32/core/hal_remote.c.

La procédure de démarrage de la machine, lors de la mise sous tension, a donc principalement pour but de construire - dans chaque cluster - ces structures de données, locales ou distribuées. La procédure de démarrage du système se fait en trois étapes, réalisées successivement par le preloader, le bootloader, et le kernel lui-même. Elle nécessite de générer trois fichiers binaires exécutables (au format .elf) décrits ci-dessous.

3.1 preloader

Le fichier binaire preloader.elf contient un code spécifique pour l'architecture TSAR, mais indépendant du système d'exploitation qu'on cherche à installer. Ce code est actuellement utilisé par les quatre OS portés sur TSAR : Linux, NetBSD, AlmosMKH, GietVM. Son rôle est de charger en mémoire RAM le code du bootloader spécifique au système d'exploitation qu'on veut charger. Il est stocké dans la ROM de boot externe, et peut donc être directement utilisé par n'importe quel coeur de la machine dès la mise sous tension. Ce preloader fait donc très peu de choses, mais nécessite cependant l'accès à deux périphériques: (i) un terminal TTY pour afficher des messages, (ii) le disque externe contenant le code du bootloader à charger en mémoire.

L'accès au disque externe et le chargement du bootloader ne sont exécutés que par le coeur[0[0] (coeur 0 du cluster 0). Les autres coeurs de la plate-forme commencent à exécuter le code du preloader, mais se bloquent immédiatement en mode basse consommation, et ne seront réveillés que plus tard par une IPI (Inter Processor Interrupt).

Lorsque le preloader qui s'exécute sur le coeur[0][0] a terminé le chargement du bootloader, le coeur[0][0] commence à exécuter le code du bootloader. Vous trouverez le code source du preloader dans le fichier ​tsar/softs/tsar_boot/reset.S.

3.2 bootloader

Le fichier binaire boot.elf contient le code du bootloader, qui est à la fois spécifique à l"architecture TSAR, et spécifique au système d'exploitation almos-mkh. Ce fichier est stocké sur le périphérique de stockage (disque externe), mais pas dans un système de fichier, car le preloader ne gère pas de système de fichier. Le fichier est directement stocké dans les premiers secteurs du disque externe, précisément réservés pour cet usage.

La première tâche du bootloader est de charger en mémoire le code du système d'exploitation, initialement stocké sur le disque externe. Pour éviter de créer un point de contention lors des appels système, et pour permettre à chaque instance du noyau de gérer ses propres structures de données propres, les deux segments seg_kcode et seg_kdata constituant le code kernel sont répliqués dans chaque cluster. Ceci est évidemment une originalité par rapport à d'autres OS. Le coeur[0][0] exécutant le code du bootloader commence par charger dans la mémoire RAM du cluster[0] les deux segments définis dans le fichier kernel.elf. Quand il a fini ce chargement, il réveille les coeurs[i][0] des autres clusters au moyen d'une IPI. À partir de cet instant, les coeurs[i][0] des autres clusters[i] peuvent - en parallèle - recopier ce code kernel dans la mémoire locale de chaque cluster[i].

La seconde tâche du bootloader est de charger en mémoire, à partie du disque externe de la machine, le fichier /arch_info.bin situé dans le répertoire racine. Ce fichier définit les caractéristiques de l'architecture matérielle: nombre de clusters, nombre de coeurs dans chaque cluster, taille de la mémoire physique dans chaque cluster, nombre et types des périphériques, etc.). Ici encore le coeur[0][0] commence par charger le contenu du fichier arch_info.bin dans la mémoire du cluster[0]. Puis, tous les coeurs[i][0] recopient le fichier dans la mémoire locale du cluster[i], et construisent une structure de données boot_info[i] locale à chaque cluster[i] contenant uniquement les informations utiles pour configurer l'instance de l'OS du cluster[i].

Lorsque ceci est terminé, dans chaque cluster[i], le coeur[i][0] réveille les autres coeurs[i][j] du cluster[i], et tous les coeurs[i][j] peuvent se brancher - en parallèle - à la fonction kernel_init(), chargée de construire les structures de données du noyau et d'initialiser les périphériques.

Vous trouverez code source du bootloader pour TSAR dans le fichier ​almos-mkh/boot/tsar_mips32/boot.c.

3.3 kernel_init

Le fichier kernel.elf contient le code binaire du système d'exploitation almos-mkh. Ce fichier est stocké sur le périphérique de stockage (disque externe), dans le répertoire /bin/kernel/. Dans chaque cluster[i], la fonction kernel_init() prend pour unique argument un pointeur sur la structure boot_info[i], qui a été construite et initialisée par le bootloader, et se trouve stockée au début du segment seg_kdata. La fonction kernel_init() utilise les informations présentes dans cette structure pour initialiser dans chaque cluster, les structures de données locales au cluster, c'est-à-dire l'allocateur de mémoire physique, les ordonnanceurs des coeurs, les périphériques et les structures devices.Elle initialise aussi les structures de données distribuées telles que le VFS ou la structure DQDT, qui permet d'enregistrer le taux d'utilisation de la mémoire dans chaque cluster, ou la charge de chacun des coeurs de la plateforme.

Lorsque ces initialisions sont terminées, la fonction kernel_init() exécutée par le coeur[0][0] construit la structure de donnée représentant le premier processus utilisateur, appelé init. Ce premier processus a pour rôle de créer, en utilisant l'appel système fork, un ou plusieurs processus shell. Chaque processus shell est un processus interactif permettant à l'utilisateur de lancer les applications qu'il souhaite. Les fichiers binaires contenant le code application (fichiers init.elf, ksh.elf, appli.elf, sont traditionnellement stockés dans le répertoire /bin/user/ du disque externe.

Vous trouverez le code source de la fonction kernel_init dans le fichier ​almos-mkh/kernel/kern/kernel_init.c.

4. Construction de la plate-forme

Vous devez maintenant utiliser les Makefile pour générer les fichiers décrits ci-dessous, et construire le disque externe utilisé par le simulateur.

• tsar.x : simulateur de la machine TSAR,
• preloader.elf : code de boot indépendant de l'OS,
• boot.elf : code de boot pour charger almos-mkh,
• kernel.elf : code du noyau almos-mkh,
• arch_info.bin : description de l'architecture matérielle pour almos-mkh,
• init.elf, ksh.elf, hello.elf, etc : différents codes applicatifs.

4.1 paramètrage du matériel

Le simulateur tsar.x est générique puisqu'on peut facilement faire varier:

• le nombre de clusters, défini par les paramètres x_size & y_size.
• le nombre de coeurs par cluster, défini par le paramètre ncores.
• les caractéristiques des périphériques internes et externes.
• la segmentation de l'espace adressable physique dans chaque cluster.

Le système d'exploitation almos-mkh a également besoin d'être configuré en fonction des caractéristiques de l'architecture cible.

• Le fichier permettant de configurer le matériel est le fichier texte hard_config.h, qui est inclus dans le fichier top.cpp (langage SystemC) permettant de générer le simulateur.
• Le fichier permettant de configurer le logiciel système est le fichier binaire arch_info.bin qui est lu sur le disque de l'architecture matérielle par le bootloader lors du démarrage de la plate-forme.

Pour éviter une incohérence entre ces deux fichiers de configuration, on génère ces deux fichiers à partir d'un unique fichier script arch_info.py, écrit en langage Python. Les spécifications détaillées de ce script sont définies ​ici.

En plus de ce script python, les paramètres matériels les plus importants (nombre de clusters, nombre de coeurs par cluster) peuvent être redéfinis grâce au fichier ​almos-mkh/params-hard.mk.

4.2 Génération du disque de la machine TSAR

Le but de cette étape est de produire une image disque au format FAT32 qui sera le disque utilisé par la machine TSAR. Ce disque contient les fichiers suivants:

• le fichier boot.elf, directement stocké dans le secteur 2 du disque.
• le fichier arch_info.bin, stocké dans le répertoire racine / du système de fichier.
• le fichier kernel.elf, stocké dans le répertoire /bin/kernel du système de fichier.
• les fichiers applications init.elf, ksh.elf, hello.elf, etc., stockés dans le répertoire /bin/user du système de fichier.

Pour construire cette image disque, le Makefile utilise le package standard mtools, qui fournit un ensemble d'outils pour construire et manipuler une image disque FAT32 sous Linux.

Pour utiliser ce package, il faut créer un fichier de configuration .mtools, qui doit être stocké dans votre répertoire home. La commande suivante permet de créer ce fichier :

echo "mtools_skip_check=1" >> ~/.mtoolsrc

Editez le fichier ​almos-mkh/params-hard.mk pour spécifier une architecture contenant un seul cluster et un seul coeur par cluster.

cd /dsk/l1/misc/almos-mkh_tsar_moi/almos-mkh
vi params-hard.mk

Puis lancez le Makefile situé dans le répertoire almos-mkh. Ce Makefile est hiérarchique. Il génère dans les sous-répertoires almos-mkh/kernel/build, almos-mkh/boot/tsar_mips32/build, ou almos-mkh/user/appli/build, les différents fichiers binaires exécutables au format .elf, et construit dans le répertoire almos-mkh/hdd l'image disque virt_hdd.dmg, qui est utilisée comme disque externe par la machine TSAR.

make

Vous pouvez vérifier le contenu de l'image disque virt_hdd.dmg générée en utilisant la commande mdir du package mtools:

mdir -/ -b -i hdd/virt_hdd.dmg ::/

L'exécution de ce Makefile permet également de générer le fichier almos-mkh/hard_config.h (pour configurer le simulateur tsar.x), et le fichier almos-mkh/arch_info.bin (pour configurer almos-mkh).

Ouvrez le fichier généré almos-mkh/hard_config.h pour vérifier que les informations qu'il contient sont cohérentes avec les informations contenues dans le fichier source (python) qui se trouve dans tsar/platforms/tsar_generic_iob/arch_info.py.

vi hard_config.h

4.3 Compilation du preloader

Le but de cette étape est de produire le code du préloader, sous la forme du fichier binaire preloader.elf, dont le contenu est préchargé par le simulateur tsar.x dans la ROM de boot.

Il faut se placer dans le répertoire tsar/softs/tsar_boot pour lancer la compilation.

cd /dsk/l1/misc/almos-mkh_tsar_moi/tsar/softs/tsar_boot/
make

Attention: Le code du preloader dépend du nombre de coeurs et du nombre de clusters, et il utilise le fichier hard_config.h pour obtenir cette information. Il faut donc re-compiler le préloader chaque fois qu'on modifie la plate-forme matérielle.

4.4 Génération du simulateur tsar.x

Le but de cette étape est de produire le simulateur tsar.x, pour l'architecture matérielle définie dans le fichier hard_config.h. Placez-vous dans le répertoire tsar/platforms/tsar_generic_iob qui contient le fichier top.cpp décrivant l'architecture TSAR.

La génération du fichier exécutable tsar.x utilise évidemment les composants matériels et logiciels de la plate-forme SoClib, et en particulier l'outil soclib-cc que vous avez déjà utilisé dans les TPs précédents.

cd /dsk/l1/misc/almos-mkh_tsar_moi/tsar/platforms/tsar_generic_iob/
make

Attention : Le fichier hard_config.h étant inclus dans le fichier top.cpp, il faut regénérer le simulateur tsar.x, à chaque fois que l'on change la configuration matérielle.

5. Plate-forme mono-processeur

Placez-vous dans le répertoire tsar/platforms/tsar_generic_iob pour lancer le simulateur.

./tsar.x

Deux fenêtres apparaissent :

• term0 : C'est la console du noyau où s'affichent les traces du système (pensez à l'agrandir un peu pour avoir un affichage du logo en entier).
• term1 : C'est un terminal utilisateur sur lequel le processus init démarre le premier schell ksh.

Sur le terminal term1, tapez la commande help en réponse au prompt [ksh], pour obtenir la liste des commandes disponibles.

[ksh] help <return>

Utilisez la commande ls pour obtenir la liste des applications disponibles dans le répertoire /bin/user.

[ksh] ls <return>

Utilisez la commande load pour lancer l'application hello.

[ksh] load /bin/user/hello.elf <return>

Pour arrêter l'exécution, de cette application, tapez <CTRL C>.

Lancez maintenant l'application idbg, qui permet d'afficher l'état courant de certaines structures internes du noyau.

[ksh] load /bin/user/idbg.elf <return>

Lorsque le prompt de l'application idbg s'affiche, tapez la commande h pour obtenir la liste des commandes idbg disponibles.

[idbg] h

Pour obtenir l'état des processus créés dans le cluster 0, tapez p puis 0. Tapez x pour tuer l'application idbg et redonner la propriété du terminal term1 à l'application ksh.

Pour arrêter la machine virtuelle, Tapez <CTRL C> dans le terminal où vous avez lancé le simulateur tsar.x, ce qui correspond à un hard reset.

6. Plate-forme multi-coeurs

Éditez le fichier : ​almos-mkh/params-hard.mk et modifier les paramètres X_SIZE, Y_SIZE, NCORES, NB_TTYS pour générer le simulateur d'une plate-forme matérielle comportant 4 clusters, 2 coeurs par cluster, et trois terminaux TTY. Avoir trois terminaux TTY permet d'avoir une console système, et deux shells en parallèle.

Placez-vous dans le répertoire almos-mkh, et supprimer tous les fichiers générés dans le répertoire almos-mkh.

cd /dsk/l1/misc/almos-mkh_tsar_moi/almos_mkh
make clean

Recompilez successivement

1. le code noyau (fichiers boot.elf, kernel.elf, hard_config.h, arch_info.bin,
2. le fichier preloader.elf,
3. le simulateur tsar.x

Lancez à travers le shell une ou plusieurs applications hello, en parallèle

7. Ajout d'une application utilisateur

Vous allez maintenant définir une nouvelle application utilisateur, la compiler, et enregistrer le fichier contenant le code binaire exécutable de cette application sur le disque utilisé par Tsar.

Le code source des applications utilisateur sont stockées dans le répertoire almos-mkh/user :

cd /dsk/l1/misc/almos-mkh_tsar_moi/
cd almos-mkh/user
ls
   convol  display  fft  hello  idbg  init  ksh  pgcd  sort  transpose

Vous allez dupliquer l'application hello en application bye :

cp -r hello bye

Dans le répertoire bye se trouve :

cd bye
ls -1
   build       -->  répertoire utilisé pour la compilation
   hello.c     -->  code source de l'application qu'il faut renommer en bye.c
   hello.ld    -->  ldscript utilisé par l'éditeur de lien pour produire l'exécutable qu'il faut renommer en bye.ld
   Makefile    -->  Makefile de compilation

Renommez hello.c et hello.ld respectivement en bye.c et bye.ld, puis:

1. Ouvrez bye.c
   Cette application créé deux threads exécutant le même code affichant chacun un message reçu en argument et attendant l'appui d'une touche. Changez juste les messages affichés.

2. Ouvrez bye.ld
   Ce fichier contient la description du mapping des sections produites par le compilateur C dans l'espace d'adressage de l'application. Il n'y a rien à changer ici parce que toutes les applications utilisent le même mapping.

3. Ouvrez Makefile
   Remplacer partout hellopar bye.

Vous allez maintenant modifiez le Makefile d'almos-mkh qui se trouve dans le répertoire racine d'almos-mkh.

1. Modifiez la cible .PHONY: pour ajouter user/bye/build/bye.elf
   Cette cible permet d'imposer la recompilation même quand les sources n'ont pas été modifiés.

2. Modifiez la cible compile: pour ajouter user/bye/build/bye.elf
   Ceci va permettre de compiler la nouvelle application.

3. Modifiez la cible clean: pour exécuter le Makefile dans user/bye
   Ceci va permettre de nettoyer le répertoire build de bye.

4. Ajouter la règle de production de l'exécutable bye.elf(c'est à la fin du Makefile)
   Notez que c'est dans cette règle que le nouvel exécutable est ajouté sur le disque de tsar.

Vous devez maintenant recompilez almos-mkh. Il n'est pas nécessaire de recompiler le preloader et le simulateur tsar.x, puisque l'architecture matérielle n'a pas été modifiée. Lancez l'exécution des applications hello.elfet bye.elfdans deux terminaux différents.

8. Questions

Répondez succinctement avec vos propres mots aux questions suivantes.

1. Quelle est la taille (en octets) de l'espace d'adressage physique. Quelle est la taille de l'espace virtuel?

2. Quelles sont les tailles des tables de 1er et 2e niveau d'une table de page ?

3. À quoi servent les bits V et D dans les tables de 1er et de 2e niveau de la table des pages ?

4. Quel est le nombre d'entrées de chaque TLB ?

5. Que signifie LL/SC ? À quoi servent ces instructions ?

6. Combien de réseaux DSPINs indépendants interconnectent les caches L1 et les caches L2 ? Pourquoi ?

7. Dans quel fichier doit-on indiquer le nombre de cores et le nombre de clusters ?

8. Quelle est la différence entre le bootloader et le preloader ?

9. Dans quel(s) cluster(s) est stocké le code du noyau almos-mkh?

10. Les données du noyau sont-elles répliquées dans tous les clusters, ou sont-elles distribuées sur tous les clusters ?

11. À quoi sert le fichier ldscript utilisé pour la production d'un exécutable ?

12. Pourquoi toutes les applications utilisateur utilisent-t-elles le même ldscript ?

13. Pourquoi doit-on modifier l'image disque utilisée par TSAR pour ajouter une application ?