Le code du programme qu'exécute un processus s'appelle un module exécutable ou load module. Nous décrirons au chapitre VI comment on le construit à partir d'un programme écrit en langage évolué, C, Fortran... Il est stocké sur le disque et chargé dans la mémoire au moment de l'exécution. Le module exécutable n'est pas exactement l'image du code en cours d'exécution pour de nombreuses raisons.
Tout d'abord les adresses à manipuler ne peuvent pas être connues à l'avance car un programme peut être chargé en différents endroits de la mémoire. De plus il utilise différentes ressources dont les adresses sont également inconnues jusqu'au moment du chargement : adresses des tampons, éléments de codes partagés avec d'autres processus et déjà existants dans la mémoire, bibliothèques dynamiques, localisation de nombreuses tables : mot d'état, fichiers, périphériques.... Le chargeur ou loader doit donc modifier ce code pour établir tous les liens nécessaires. Son travail dépend beaucoup de la structure du module exécutable. Nous envisagerons ici uniquement le calcul des adresses des objets internes au programme (localisation des variables, adresses de débranchement dans les tests et les appels de procédures internes...).
 |
figure 5.9 : Structure d'une mémoire
linéaire et d'une mémoire segmentée. |
Le module peut être constitué d'un seul bloc chargé à des adresses contiguës dans la mémoire. Il suffit alors d'ajouter la valeur de l'adresse où a été placée le début de ce module, partout où une adresse apparaît dans ce code, notamment dans les débranchements, pour calculer les vraies adresses en mémoire.
Ce module peut être segmenté. Il est constitué de plusieurs morceaux ou segments, chacun chargé à des adresses contiguës. Deux segments ne sont pas, à priori, voisins dans la mémoire. Le code et les données, c'est à dire l'ensemble des constantes et des variables, sont rangés dans des segments séparés. Il existe donc au minimum deux segments. L'adresse d'un objet, à l'intérieur du programme, est obtenue par la connaissance du numéro i du segment et de la valeur a du déplacement à l'intérieur de celui-ci (fig. 5.9).
L'allocation de la mémoire comporte tout d'abord une étape où on copie le module exécutable dans la mémoire physique. Entre autre il faut :
- gérer la mémoire physique, c'est à dire allouer les emplacements de chargement et transférer l'information. Nous évoquerons ce point dans la section 5.5
- réaliser les correspondances entre adresses virtuelles et physiques. On remplace les adresses, telles qu'elles ont été calculées par le compilateur, par les vraies adresses en mémoire.
- assurer les protections mutuelles entre les divers éléments de mémoire alloués aux différents processus et charger le contenu des tables de contexte.
Lorsque le module exécutable est plus petite que la mémoire physique disponible, le chargement ne présente pas de difficulté. On peut utiliser une politique d'allocation statique, comme dans le cas de DOS. La correspondance physique-virtuelle est établie au début . Il suffit d'ajouter la valeur n de l'adresse physique de chargement à toutes les adresses virtuelles du module.
 |
| figure 5.10 : Principe des overlays |
Lorsque ce module est plus grand que la mémoire physique il est encore possible d'exécuter le programme si l'on peut employer une politique d'allocation dynamique. C'est ce qu'on fait dans la technique d'overlay. Le programme est découpé en segments qui ne sont pas tous chargés simultanément. Dans le schéma de la figure 5.10, par exemple, un programme est constitué de trois segments A, B, C. On charge toujours A puis successivement B puis C. Ceci doit évidemment être prévu dans la programmation afin qu'aucun élément de B ne fasse référence à un élément de C et réciproquement. On doit également ajouter les instructions nécessaires à ces allocations. La technique d'overlay est tombée en complète désuétude depuis l'apparition de la mémoire virtuelle paginée que nous décrirons dans la section 5.5. Elle est encore employée par DOS et reste valable pour les dispositifs spécialisés où la taille de la mémoire est limitée.
Copyright Yves Epelboin, université P.M. Curie, février 2003, MAJ
15 mars, 2006
