Obligement - L'Amiga au maximum

Samedi 17 novembre 2018 - 04:02  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles en d'autres langues


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Logiciels
 · Jeux
 · Scène démo
 · Divers


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


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

assembleur
assembleur


[Retour en haut] / [Retour aux articles]