Project

General

Profile

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 :)