= Création d'un nouveau processus

== Création de l'environnement de travail

Vous allez devoir recréer l'environnement de travail sur les nouvelles machines en vous référant au [https://www-soc.lip6.fr/trac/sesi-soclib/wiki/smc1 premier TP sur ALMOS-MKH]. En résumé :

{{{
#copie des sources
cd /dsk/l1/misc
scp schmitt:/dsk/l1/misc/almos-mkh_tsar.tbz2 .
tar xvjf almos-mkh_tsar.tbz2

# definition des variables d'environnement
cd /dsk/l1/misc/almos-mkh_tsar
source env.sh

# compilation du noyau, des applications et generation du disque de tsar
cd /dsk/l1/misc/almos-mkh_tsar/almos-mkh
make

# compilation du prelaoder 
cd /dsk/l1/misc/almos-mkh_tsar/tsar/softs/tsar_boot/
make

# compilation du simulateur
cd /dsk/l1/misc/almos-mkh_tsar/tsar/platforms/tsar_generic_iob/
make

# execution du simulateur
./simul.x
}}}

Dans la fenêtre '''term1''' du simuteur, lorsque le prompt du schell [ksh] apparait, vous pouvez exécuter l'application hello.elf
{{{
load /bin/user/hello.elf
}}}

Désormais le moteur de simulation est systemcass qui profite de la structuration des composants SoCLib.
Un composant SoCLib sépare explicitement les fonctions de transition, de génération de Moore et de génération de Mealy dans ses automates.
Sans entrer dans les détails, cela permet à systemcass de n'exécuter qu'une seule fois par cycle les fonctions de transition et de génération de Moore et limiter la simulation par relaxation aux fonctions de Mealy.
Dans le cas de TSAR, cela permet un gain en vitesse de 400% environ.

En outre, systemcass permet de produire simulateur parallèle (s'exécutant en parallèle sur un ordinateur multi-core) gràce à l'API OpenMP. 
Le modèle SystemC de TSAR contient déjà les directives de parallélisation.
Le grain de parallélisation est le cluster, c'est-à-dire qu'un thread d'OpenMP peut exécuter un nombre entier de clusters.
Ainsi, on ne peut bénéficier de la parallélisation que pour les architectures de TSAR multi-clusters.

Pour demander la parallélisation, il suffit de lancer le simulateur avec le paramètre `-THREADS x`, où x est le nombre de threads OpenMP demandé (qui doit être au plus égal au nombre de cores, ici 6). Par exemple, pour une plateforme TSAR à 4 clusters (quel que soit le nombre de cores par cluster), après voir compilez, vous écriez :
{{{
cd /dsk/l1/misc/almos-mkh/tsar/plateforms/tsar_generic_iob/
./simul.x -THREADS 4
}}}

A titre indicatif, le simulateur de tsar_generic_iob s'exécute à environ 200KHz pour 1 cluster à 1 core sur un core du PC et à environ 100KHz pour 4 clusters à 4 cores (16 cores) en tout sur 4 cores du PC. 

== Questions

1. Démarrez le simulateur et exécuter l'application idbg.elf `load /bin/user/idbg.elf`. Cette application permet d'afficher dans la fenêtre '''term0''' l'état de certaines structures du noyau. 
   a. La commande `h` permet d'obtenir de l'aide. 
   a. La commande `p`, déterminer le nombre de processus sur le cluster 0.
   a. La commande `s`, déterminer le nombre de threads alluoués au core 0 du cluster 0.

2. Modifiez dans le fichier `kernel/kernel_config.h` l'état des variables `DEBUG_PROCESS_DESTROY`, `DEBUG_PROCESS_MAKE_EXEC` et `DEBUG_PROCESS_MAKE_FORK`, recompilez ALMOS-MKH et exécutez le simulateur (il n'est pas nécessaire de le recompiler le simulateur si vous ne modifiez pas la plateforme).
  * Les étapes du fork et de l'exec des process ksh s'affichent dans `term0`, commentez les messages concernant le `ksh[1]` (le code des fonctions fork et exec (dans le noyau) se trouve [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/process.h kernel/kern/process.h] et [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/kernel/kern/process.c kernel/kern/process.c].

3. Pour avoir deux clusters de 1 cores, il faut modifier la plateforme  en changeant de `1` à `2` l'état de la variable `Y_SIZE` du fichier `almos-mkh/params-hard.mk`.  Il faut ensuiten recompiler le systeme ALMOS-MKH pour produire le disque, le préloader (dans `tsar/softs/tsar_boot/`) pour produire la rom et le simulateur, puis exécuter avec `./simul -THREADS 2`. Remaquez que puisqu'il y a deux clusters, on demande 2 threads d'OpenMP sur 2 cores du PC (votre PC a 6 cores). Pour voir Modiifiez l'état des variables `DEBUG_RPC_PROCESS_MAKE_FORK` et `DEBUG_RPC_THREAD_KERNEL_CREATE` du fichier `kernel/kernel_config.h` pour voir les commandes RPC.
 * Comme il y a deux clusters, il y a de la réplication pendant la phase de boot (avant l'affichage de la banière). Notez ce qui est répliqué et à quel moment.

4. Je vous propose de suivre la création du process hello.elf, grâce aux messages écrits par le noyau et dans le code du noyau. Pour faciliter le parcours du code, je vous propose d'utiliser visual studio et d'ouvrir le répertoire almos-mkh. Tous les fichiers d'almos-mkh apparaissent à gauche. Vous pouvez par exemple ouvrir kernel/kern/process.c et ensuite parcourir le code en hypertext.
 * Avec `idbg.elf` (ou juste avec les messages du noyau) dîtes comment sont répartis les threads de l'application `hello.elf`.
 * Représenter le graphe d'appel des fonctions `sys_fork()`, `sys_exec()` et `sys_thread_create()`. Dans ce graphe, vous ne faites pas figurer les arguments (c'est pour savoir quelles sont les fonctions appelées), vous ne mettez pas non plus le code DEBUG.
 * Représenter en pseudo-code la trace d'exécution du lancement de l'application `hello.elf`.