Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : Assembleur - FreeMem (libérer la mémoire)
(Article écrit par Max et extrait d'Amiga News Tech - janvier 1991)
|
|
Amnésie internationale
Dans la société actuelle, vu la vie de dingue que l'on mène, les problèmes de l'humanité se résument en trois mots :
le sexe, l'argent et la mémoire. Si je ne puis rien faire dans les deux premiers cas, le programme que je vous propose
ici devrait balayer d'un coup tous vos tracas en ce qui concerne le troisième.
Lorsque l'on développe quelque chose de sérieux sur Amiga, ou dans un cas plus général, lorsque l'on utilise des
programmes du domaine public - voire du commerce - mal foutus, il arrive souvent que l'on se retrouve, après exécution,
avec moins de mémoire qu'avant. Un des exemples les plus connus de cet état de fait sont les 48 octets que "mangent"
certains programmes des temps préhistoriques, à cause d'un Lock() non libéré (tiens, en parlant de ça, un message
personnel à François Lionet : est-ce que, dans une prochaine version d'AMOS, tu comptes le libérer, ce Look() que
tu gardes jalousement enfoui quelque part dans les méandres de ton source ?).
Oui, je sais ce que vous allez dire :
48 octets, c'est trois fois rien, on s'en fout. Ben non, justement, on s'en fout pas. D'abord parce que ça fait
pas propre, genre travail inachevé et puis dites-vous bien que 48 octets plus 48 octets plus 48 octets plus...
ça peut déboucher sur une situation de manque de mémoire obligeant à une inutile réinitialisation.
Dans quel état j'ère ?
Le petit utilitaire de ce mois-ci, légèrement inspiré d'un des programmes de démonstration fournis avec Devpac 2,
mais que je me suis fait depuis déjà belle lurette (la première version date de 1988 !) ouvre une petite fenêtre
dans laquelle sont affichées en permanence les quantités de mémoire Chip et Fast libres, ainsi que le total des
deux. Ces informations sont rafraîchies toutes les 1/2 secondes, c'est-à-dire bien plus souvent que ne
le fait le Workbench dans sa barre de menu. De plus, elles sont tout le temps visibles, plus besoin de
cliquer sur la fenêtre du Workbench pour y accéder.
Du point de vue technique, la fenêtre est ouverte dans le coin bas gauche de l'écran, pour éviter tant
que faire se peut tout recouvrement par une autre fenêtre. Les quantités de mémoire libre sont obtenues
grâce à la fonction AvailMem() d'Exec pour la Chip et la Fast, le total n'étant, comme son l'indique,
que la somme de ces deux valeurs. Ces trois nombres sont convertis en ASCII dans un tampon mémoire
par la fonction RawDoFmt(), ce tampon mémoire étant par la suite affiché dans la fenêtre par
PrintlText() de la bibliothèque Intuition.
Une petite précision supplémentaire : ce ne sont pas les quantités de mémoire disponible qui
sont affichées, mais bel et bien de mémoire libre. Cette distinction découle de la manière dont
Exec gère sa mémoire : imaginons pour les besoins de l'exemple que deux tâches tournant
simultanément sur un Amiga avec 512 ko de mémoire, réservent de la mémoire via AllocMem() ou
autre : Exec alloue à la première un bloc allant de $10000 à $1FFFF et à la seconde, un bloc
allant de $20000 à $23FFF.
Si la première tâche libère sa mémoire avant la seconde, la situation
sera alors la suivante : un bloc de mémoire libre allant de $0 à $FFFF (longueur : $10000 octets),
suivi d'un bloc occupé par la seconde tâche de $10000 à $1FFFF (longueur : $10000 octets aussi),
suivi d'un bloc libre de $20000 à $7FFFF (longueur $60000 octets). Dans cette configuration,
AvailMem() indiquera un total de $70000 octets libres, mais AllocMem() ne pourra allouer un
bloc que de $60000 octets maximum.
Imaginez maintenant cette situation dans un environnement où une bonne dizaine
de tâches tournent sans même que l'on s'en rende compte (les différents périphériques logiques et bibliothèques
ouverts, le Workbench, etc.). C'est pourquoi il est possible de demander la taille du plus gros
bloc disponible en spécifiant lors de l'appel à AvailMem() l'attribut MEMF_LARGEST en sus
de MEMF_FAST, MEMF_CHIP ou MEMF_PUBLIC. Ce qui n'est pas fait ici, mais rien ne vous en empêche si
ça vous branche.
Comme d'habitude, ce programme a été écrit avec Devpac 2 (son adaptation pour K-Seka demandera
quelque travail aux masos qui voudraient s'y attaquer) et ne s'exécute qu'à partir du CLI ou,
bien mieux, de la startup-sequence. En prime, une superbe démonstration des possibilités des
macros de Devpac (regardez de plus près la macro Version...).
|
