Le PRG
Le PRG a ceci comme avantage: Il est relogeable, du moins, si votre assembleur vous le permet. Mais il y a beaucoup de chance pour que cela soit le cas !
En effet, par le passé, comme sur un Atari 800XL ou un C64, vous deviez préciser l'adresse où serait logé le code machine en mémoire via la speudo fonction ORG. Toutes les références se faisait par la suite par rapport à cette adresse lors de l'assemblage.
Inconvénient :
- Surtout ne pas se tromper d'adresse lors du chargement en mémoire, sinon risque d'écrasement de données/codes et suivi d'un plantage.
- Généralement impossible de charger le programme dans une autre zone de la mémoire puisque les références ne peuvent plus changer une fois le code généré.
Sur un ST, lors de la création d'un programme assembleur, vous n'indiquez jamais l'adresse de chargement. En fait, l'assembleur considère toujours que le programme sera chargé à l'adresse 0 (Ce qui est évidemment impossible, puisque l'on sait que cette adresse correspond à un vecteur vers le programme d'initialisation du ST. Ce vecteur étant en ROM...).
Ce qui veut dire que les références sur des datas initialisées ou non (BSS) ou sauts (JMP/JSR) dans le code deviennent des valeurs de déplacement (offset). Lors du chargement, le système va allouer toute la mémoire disponible dans la Transient Program Area (ou TPA, correspond à la mémoire non utilisée par le système). Puis il va charger le programme au début de cette allocation.
Ensuite, il regarde si le programme est relogeable. Cette information est générée par l'assembleur et se trouve dans l'entête du programme. Si c'est le cas, il lui faut alors repasser dans le code pour mettre à jour tous ces déplacements/références avec l'adresse réelle de début du code utilisée pour cette session. A noter que ces informations seront récupérables dans la page de base après chargement du programme.
Le hic:
Comme je viens de l'écrire, le système va s'allouer toute la mémoire disponible pour pouvoir charger le code. Mais pourquoi ?
Il est effet impossible au système de connaître à l'avance la taille réelle du code. En effet, la taille du fichier PRG ne prend pas en compte la section BSS (données non initialisées, donc inutile d'enregistrer celà dans le fichier PRG, sinon perte de place sur la disquette). De plus qui sait ce que vous voulez faire ?
Alors tout va dépendre de ce que vous voulez faire avec votre programme:
- Soit votre programme ne sera pas résident, il est lancé et ne chargera pas d'autres programmes. Il se fermera ensuite quand le boulot sera fait. Dans ce cas, il libèrera la mémoire comme un grand. Mais vous ne pourrez pas vous allouer de la mémoire dans votre code. En effet, si vous lancez la fontion GEMDOS MALLOC, elle vous retournera qu'il n'y a plus de mémoire disponible ! Ce n'est pas non plus ce qu'il y a de plus propre...
- Soit votre programme sera résident ou vous voulez charger d'autres programmes ou encore utiliser la fonction MALLOC du GEMDOS. Dans ce cas, il faut libérer la mémoire non utilisée par le code: Mais ce n'est heureusement pas trop compliqué : Voir comment réorganiser la Transient Program Area.
La terminaison du programme:
Avant de mettre fin à notre programme, n'oubliez pas de:
- Libérer la mémoire allouée pendant l'exécution de notre programme,
- Femer tous les fichiers ouverts
- Remettre éventuellement les bonnes valeurs dans les vecteurs du systèmes que vous auriez modifié
- Le son
- Rétablir les couleurs, la résolution et j'en passe...
Bien entendu, tout va dépendre de ce que va faire le programme. Quant-à l'ordre des séquences de restauration avant terminaison, je vous laisse le soin d'y réfléchir.
Un programme peut en effet se terminer de différentes manières:
Les normales sont :
Fin du programme, On a terminé avec le programme, on le quitte donc. On doit alors remettre la machine dans l'état où elle a été trouvée !
Le programme reste résident, évidemment, dans ce cas, certaines choses (et cela peut-être n'importe quoi) ne seront pas restaurées puisque notre programme peut encore intervenir à tout moment.
Il existe aussi:
L'arrêt par un controle-C
Ou suite à un plantage (les sympathiques petites bombes !!!).
Remarque: Il est possible de passer des paramètres à un .PRG. Dans ce cas, reportez vous au chapitre concernant les exécutables .TTP, ce sera la même chose.