La pile la mémoire les bibliothèques¶

Objectif : généralités

STATUT : PARTIEL
Version : 0.2
Auteur : iri
Date : Novembre 2010 (initialement diffusé sur http://www.irizone.net)
Licence du tutoriel : GNU FDL v1.3
Licence du code source : GNU/GPL v3

Codes sources¶

Le code source de Scol est disponible et accessible publiquement depuis le Scolring :
http://redmine.scolring.org.
Si vous souhaitez participer et publier vos travaux sur la plateforme communautaire
officiel, enregistrez-vous via l'interface prévue à cet effet (en haut à droite).

Le noyau (kernel)¶

Outre un certain nombre de fonctions standards et communes et de la gestion réseaux
(gestion des canaux TCP et API réseau notamment), le noyau gère toutes les interfaces
entre Scol et le système d'exploitation sous-jacent, notamment mémoire et par conséquent,
toute la gestion de la pile. C'est ce dernier point qui nous intéressera ici.

La pile et la mémoire¶

La pile utilisée par Scol est d'un fonctionnement tout à fait standard. Les
opérations habituelles de base sont possibles, comme le montre ce shema ci-dessous :

http://www.irizone.net/img/prog_pile.png (image 1)

• PUSH : pousse un élément dans la pile, i.e. l'ajoute à la dernière position.
  Le nouvel élément prend alors l'index numéro 0, l'ancien élément (qui possédait
  donc l'index 0 avant l'opération) prend l'index 1 et ainsi de suite.

• PULL : enlève le dernier élément de la pile, i.e. l'élément possédant l'index
  0. L'élément ayant l'index 1 avant l'opération se retrouve donc avec l'index 0 après.

• SET : modifie le contenu d'un élément, i.e. remplace le contenu de l'élément
  d'index I par un nouveau contenu. Les éléments inférieurs ou supérieurs de la pile
  sont inchangés et gardent leur index respectif.

• GET : récupère le contenu d'un élément d'index I de la pile. Les éléments gardent
  leur index respectif.

• INVERT : non montré sur le shema, c'est une opération pratique qui peut se faire
  via les opérations de base. Elle consiste à échanger deux éléments de la pile :
  l'élément d'indice I1 est placé à l'index I2 et l'élément d'index I2 est placé à
  l'index I1.

Il n'est généralement pas nécessaire d'allouer dynamiquement la mémoire sauf,
évidemment, pour la création des objets Scol eux-même (et encore cela se fait par
l'intermédiaire de macros). De même, leur libération est le plus souvent transparente
et automatiquement géré lors de la destruction de l'objet Scol. Bien évidemment,
il peut être nécessaire d'allouer dynamiquement (malloc) pour des objets non Scol
comme pour tout code C (new pour C++) classique, dès que ces objets ne sont pas intégrés
à la pile Scol (et de ne pas oublier de les libérer lorsqu'ils ne sont plus utiles !
suivant la loi fondamentale : à toute allocation doit correspondre une libération !!).

Pour accéder à la pile, il est plus que recommandé d'utiliser les macros et
fonctions prédéfinies :

• Pour l'opération PUSH : MMpush. L'élément à ajouter devrait être un pointeur.
  Son prototype est : int (*MMpush) (mmachine m, int val);
• Pour l'opération PULL : MMpull.
  Son prototype est : int (*MMpull) (mmachine m);
• Pour l'opération GET : MMget. L'index de l'élément souhaité est passé en argument
  Son prototype est : int (*MMget) (mmachine m, int i);
• Pour l'opération SET : MMset
  Son prototype est : void (*MMset) (mmachine m, int i, int v);

Il en existe quelques autres que nous verrons plus tard. Retenez déjà ces 4 là !

Deux structures sont également définies et nous intéressent au premier chef :
mmachine et cbmachine.
La première définit les éléments de la pile auxquels nous pourront accéder depuis
une bibliothèque ; la seconde définit une API entre le noyau et les bibliothèques.
Il en existe une troisième, packdir, plus rarement utilisée mais néanmoins parfaitement
accessible.

Les bibliothèques¶

Il en existe plusieurs, comme vous avez pu le constater en parcourant le répertoire
"plugins" d'une installation Scol. Suivez quelques règles de bases et tout devrait
bien se passer ;-)
L'interface avec le noyau sera définie avec un fichier d'en-tête (header) que vous
ne devriez pas modifier (à moins de modifier le noyau en conséquence). Ce header est
commun à toutes les bibliothèques. Selon le projet et vos préférences, la bibliothèque
sera codée en C ou en C++ indifféremment (en utilisant des directives de préprocesseur
si besoin est).

Enfin, le chargement d'une bibliothèque se fait bien sur par le noyau, selon les
indications écrites dans le fichier usm.ini.

Pour information, le code source du noyau s'occupant du chargement / déchargement
des bibliothèques se trouve :

• sous MS Windows, dans "kernel5/src/win/hardload.c". Chaque biliothèque définie
  dans le usm.ini est enregistrée par la fonction SCregistDLL : celle-ci
  sauvegarde le nom du fichier, le nom interne à la bibliothèque de la fonction de
  chargement et le nom interne à la bibliothèque de la fonction de libération. Dans un
  second temps, elles seront effectivement chargées et ajoutées à l'environnement
  via la fonction SCloadDLLs grâce aux informations précédemment recueilies.
  La libération se fait lors de l'extinction de Scol, via la fonction SCfreeDLLs
  définie dans ce même fichier.

• sous GNU/Linux, dans "kernel5/src/linux-nox/hardload.c". Le fonctionnement est
  similaire à celui décrit pour MS Windows. Le chargement et la libération appellent
  les fonctions dlopen, dlsym et dlclose qui sont compatibles POSIX-1.
  Un billet à ce sujet.

Vous voilà à peu près prêt à développer une bibliothèque Scol :)