La pile la mémoire les bibliothèques » History » Version 1
  iri, 01/29/2013 09:35 PM 
  
| 1 | 1 | iri | h1. La pile la mémoire les bibliothèques | 
|---|---|---|---|
| 2 | |||
| 3 | Objectif : généralités | ||
| 4 | |||
| 5 | STATUT : PARTIEL | ||
| 6 | Version : 0.2 | ||
| 7 | Auteur : iri | ||
| 8 | Date : Novembre 2010 (initialement diffusé sur http://www.irizone.net) | ||
| 9 | Licence du tutoriel : GNU FDL v1.3 | ||
| 10 | Licence du code source : GNU/GPL v3 | ||
| 11 | |||
| 12 | h2. Codes sources | ||
| 13 | |||
| 14 | Le code source de Scol est disponible et accessible publiquement depuis le Scolring : | ||
| 15 | http://redmine.scolring.org. | ||
| 16 | Si vous souhaitez participer et publier vos travaux sur la plateforme communautaire | ||
| 17 | officiel, enregistrez-vous via l'interface prévue à cet effet (en haut à droite). | ||
| 18 | |||
| 19 | h3. Le noyau (kernel) | ||
| 20 | |||
| 21 | Outre un certain nombre de fonctions standards et communes et de la gestion réseaux | ||
| 22 | (gestion des canaux TCP et API réseau notamment), le noyau gère toutes les interfaces | ||
| 23 | entre Scol et le système d'exploitation sous-jacent, notamment mémoire et par conséquent, | ||
| 24 | toute la gestion de la pile. C'est ce dernier point qui nous intéressera ici. | ||
| 25 | |||
| 26 | h4. La pile et la mémoire | ||
| 27 | |||
| 28 | La pile utilisée par Scol est d'un fonctionnement tout à fait standard. Les | ||
| 29 | opérations habituelles de base sont possibles, comme le montre ce shema ci-dessous : | ||
| 30 | |||
| 31 | http://www.irizone.net/img/prog_pile.png (image 1) | ||
| 32 | |||
| 33 | * PUSH : pousse un élément dans la pile, i.e. l'ajoute à la dernière position. | ||
| 34 | Le nouvel élément prend alors l'index numéro 0, l'ancien élément (qui possédait | ||
| 35 | donc l'index 0 avant l'opération) prend l'index 1 et ainsi de suite. | ||
| 36 | |||
| 37 | * PULL : enlève le dernier élément de la pile, i.e. l'élément possédant l'index | ||
| 38 | 0. L'élément ayant l'index 1 avant l'opération se retrouve donc avec l'index 0 après. | ||
| 39 | |||
| 40 | * SET : modifie le contenu d'un élément, i.e. remplace le contenu de l'élément | ||
| 41 | d'index I par un nouveau contenu. Les éléments inférieurs ou supérieurs de la pile | ||
| 42 | sont inchangés et gardent leur index respectif. | ||
| 43 | |||
| 44 | * GET : récupère le contenu d'un élément d'index I de la pile. Les éléments gardent | ||
| 45 | leur index respectif. | ||
| 46 | |||
| 47 | * INVERT : non montré sur le shema, c'est une opération pratique qui peut se faire | ||
| 48 | via les opérations de base. Elle consiste à échanger deux éléments de la pile : | ||
| 49 | l'élément d'indice I1 est placé à l'index I2 et l'élément d'index I2 est placé à | ||
| 50 | l'index I1. | ||
| 51 | |||
| 52 | Il n'est généralement pas nécessaire d'allouer dynamiquement la mémoire sauf, | ||
| 53 | évidemment, pour la création des objets Scol eux-même (et encore cela se fait par | ||
| 54 | l'intermédiaire de macros). De même, leur libération est le plus souvent transparente | ||
| 55 | et automatiquement géré lors de la destruction de l'objet Scol. Bien évidemment, | ||
| 56 | il peut être nécessaire d'allouer dynamiquement (malloc) pour des objets non Scol | ||
| 57 | comme pour tout code C (new pour C++) classique, dès que ces objets ne sont pas intégrés | ||
| 58 | à la pile Scol (et de ne pas oublier de les libérer lorsqu'ils ne sont plus utiles ! | ||
| 59 | suivant la loi fondamentale : à toute allocation doit correspondre une libération !!). | ||
| 60 | |||
| 61 | Pour accéder à la pile, il est plus que recommandé d'utiliser les macros et | ||
| 62 | fonctions prédéfinies : | ||
| 63 | |||
| 64 | * Pour l'opération PUSH : MMpush. L'élément à ajouter devrait être un pointeur. | ||
| 65 | Son prototype est : int (*MMpush) (mmachine m, int val); | ||
| 66 | * Pour l'opération PULL : MMpull. | ||
| 67 | Son prototype est : int (*MMpull) (mmachine m); | ||
| 68 | * Pour l'opération GET : MMget. L'index de l'élément souhaité est passé en argument | ||
| 69 | Son prototype est : int (*MMget) (mmachine m, int i); | ||
| 70 | * Pour l'opération SET : MMset | ||
| 71 | Son prototype est : void (*MMset) (mmachine m, int i, int v); | ||
| 72 | |||
| 73 | Il en existe quelques autres que nous verrons plus tard. Retenez déjà ces 4 là ! | ||
| 74 | |||
| 75 | Deux structures sont également définies et nous intéressent au premier chef : | ||
| 76 | _mmachine_ et _cbmachine_. | ||
| 77 | La première définit les éléments de la pile auxquels nous pourront accéder depuis | ||
| 78 | une bibliothèque ; la seconde définit une API entre le noyau et les bibliothèques. | ||
| 79 | Il en existe une troisième, _packdir_, plus rarement utilisée mais néanmoins parfaitement | ||
| 80 | accessible. | ||
| 81 | |||
| 82 | h3. Les bibliothèques | ||
| 83 | |||
| 84 | Il en existe plusieurs, comme vous avez pu le constater en parcourant le répertoire | ||
| 85 | "plugins" d'une installation Scol. Suivez quelques règles de bases et tout devrait | ||
| 86 | bien se passer ;-) | ||
| 87 | L'interface avec le noyau sera définie avec un fichier d'en-tête (header) que vous | ||
| 88 | ne devriez pas modifier (à moins de modifier le noyau en conséquence). Ce header est | ||
| 89 | commun à toutes les bibliothèques. Selon le projet et vos préférences, la bibliothèque | ||
| 90 | sera codée en C ou en C++ indifféremment (en utilisant des directives de préprocesseur | ||
| 91 | si besoin est). | ||
| 92 | |||
| 93 | Enfin, le chargement d'une bibliothèque se fait bien sur par le noyau, selon les | ||
| 94 | indications écrites dans le fichier _usm.ini_. | ||
| 95 | |||
| 96 | Pour information, le code source du noyau s'occupant du chargement / déchargement | ||
| 97 | des bibliothèques se trouve : | ||
| 98 | |||
| 99 | * sous MS Windows, dans "kernel5/src/win/hardload.c". Chaque biliothèque définie | ||
| 100 | dans le usm.ini est enregistrée par la fonction _SCregistDLL_ : celle-ci | ||
| 101 | sauvegarde le nom du fichier, le nom interne à la bibliothèque de la fonction de | ||
| 102 | chargement et le nom interne à la bibliothèque de la fonction de libération. Dans un | ||
| 103 | second temps, elles seront effectivement chargées et ajoutées à l'environnement | ||
| 104 | via la fonction _SCloadDLLs_ grâce aux informations précédemment recueilies. | ||
| 105 | La libération se fait lors de l'extinction de Scol, via la fonction _SCfreeDLLs_ | ||
| 106 | définie dans ce même fichier. | ||
| 107 | |||
| 108 | * sous GNU/Linux, dans "kernel5/src/linux-nox/hardload.c". Le fonctionnement est | ||
| 109 | similaire à celui décrit pour MS Windows. Le chargement et la libération appellent | ||
| 110 | les fonctions _dlopen_, _dlsym_ et _dlclose_ qui sont compatibles POSIX-1. | ||
| 111 | Un "billet":http://www.irizone.net/index.php?article=18 à ce sujet. | ||
| 112 | |||
| 113 | |||
| 114 | Vous voilà à peu près prêt à développer une bibliothèque Scol :) |