Création de variable TI-BASIC et allocation de mémoire - Page 1

Bonjour !

M'intéressant à la création de fichiers TI-BASIC, j'ai lu et compris le code suivant dans la documentation de TIGCC :

HSym hsym = SymAdd (SYMSTR ("example"));
// HeapAlloc must be executed before DerefSym
// because of possible garbage collection.
HANDLE handle = HeapAlloc (100);
SYM_ENTRY *SymPtr = (DerefSym (hsym));
MULTI_EXPR *VarPtr = HeapDeref (SymPtr->handle = handle);

Mais à la suite de cet exemple ils ne créent une variable de longueur totale de 4 octets (de données, donc 6 en tout).

Ma question est la suivante : qu'est-ce que la calculette fait des 94 octets restants ? Ma seule théorie est qu'elle les considère automatiquement comme des octets 'poubelle' qui seront libérés lors du prochain garbage collection.

Lorsque l'on alloue un block mémoire, il faut normalement utiliser HeapFree() ou une de ses variantes. Là on ne peut pas l'utiliser, car l'espace mémoire est à présent associé à un fichier global. Ça me tracasserait de perdre 94 octets à chaque fois

Il faut que tu écrives toi-même la taille de la variable que tu viens de créer dans ses 16 premiers bits, non ? (à moins que l'une des fonctions que tu utilises ne le fasses déjà)

Ma seule théorie est qu'elle les considère automatiquement comme des octets 'poubelle' qui seront libérés lors du prochain garbage collection.

Non, ces octets restent alloués pour la variable... du moins tant qu'elle est en RAM. Il faudrait regarder plus finement ce qui se passe après archivage et désarchivage.

Mais mieux vaut allouer la variable tout de suite avec la bonne taille si possible, ou au moins la réallouer à la bonne taille une fois qu'on a fini d'y écrire

./2 : en effet, il faut écrire soi-même les 16 bits de taille.

C'était bête mais je n'y avais pas pensé. Merci !

Nouvelle question, à propos de la fonction high-level VarStore() :

Si comme dans l'exemple précédent on a alloué une zone de mémoire plus grosse que la taille de la variable, la fonction VarStore prendra-t-elle cela automatiquement en compte et exécutera elle-même le HeapRealloc(), ou bien faut-il le faire soi-même avant l'appel de la fonction ?


Je m'intéresse toujours à un HANDLE, donc associe le flag STOF_HESi à VarStore().

Si comme dans l'exemple précédent on a alloué une zone de mémoire plus grosse que la taille de la variable, la fonction VarStore prendra-t-elle cela automatiquement en compte et exécutera elle-même le HeapRealloc(), ou bien faut-il le faire soi-même avant l'appel de la fonction ?

Le comportement de VarStore dans ton cas d'utilisation peut probablement être observé en observant la liste des handles, avant et après l'appel à VarStore, par exemple dans le debugger de TIEmu.
Dans le cas général, le seul moyen d'être vraiment sûr du comportement de VarStore est de désassembler le code. Mais c'est difficile car VarStore est une grosse fonction avec un certain nombre de sous-routines

A moins que la table des handles te montre que la fonction VarStore est suffisamment bien faite pour procéder à la réallocation, je te conseillerai donc de faire toi-même la réallocation avant d'appeler VarStore

Je viens de regarder al doc, t'as absolument besoin de cette fonction ? Tu t'en sors pas avec SymAdd ? C'est tellement plus simple ...

J'ai juste l'impression que VarStore peut créer elle-même le handle de la variable qu'elle enregistre, si elle n'existe pas encore en tant que variable, mais par exemple en temps qu'expression dans l'estack. Quel est le comportement si le handle existe déjà ? J'en sais rien, faudrait tracer la fonction pour le savoir.

Hésite pas à redemander en tout cas si t'as un souci avec SymAdd ^^

(cross -> la solution de Lionel est évidemment bonne, mais elle représente pas mal de travail personnel et la connaissance de l'assembleur. Tu utilises probablement un char d'assaut pour tuer une mouche avec VarStore )

Hé hé, tuer une mouche à l'aide d'un char d'assaut n'est pas pour me déplaire...

Mais malheureusement je ne sais pas utiliser un char d'assaut, et je risquerais de tout démolir sans avoir touché l'insecte prétentieux !

Sinon, oui, SymAdd est bien plus simple. Cependant VarStore permet de stocker des données dans des listes/matrices Ti-Basic et de modifier des variables systèmes assez facilement.

Oui c'est sûr Mais tu veux faire quoi en fait ?

J’essaie de créer de mes petits doigts un algorithme de compression. Ne connaissant pas d'avance la taille du fichier compressé j'étais obligé d'allouer une zone mémoire plus grande.

Je ne savais pas si je devais gérer cet handle à tendance boulimique, et ne trouvais nul part de réponse à ma question.


Pour le moment il se présente juste sous la forme d'un programme qui prend en argument le nom d'un fichier, et le compresse. Appeler de nouveau ce fichier le décompresse(-ra : il reste des bugs).

Evidemment, ce n'est ni très original, ni très pratique puisque des programmes traitant, eux, plusieurs types courants de fichiers compressés, existent déjà. Mais bon, ce sera le mien.

Plus tard, je l'utiliserais certainement pour faire un jeu, mais je pense que le jour où j'aurais fini la TI-89 sera devenu un objet de collection .