Pile et allocation mémoire - Page 1

Je voudrais etre sur d'une chose : c'est pas très clair dans la doc de TIGCC :
Quand j'alloue de la mémoire avec un malloc (ou HeapAllocPtr), est-elle allouée sur la pile (c'est ce que je comprends de la doc...) ?
Si c'est bien le cas, peut-on allouer de la mémoire hors de la pile, donc en RAM, sans créer de fichier bien sur ?

avec HeapAllocPtr, tu alloues un bloc en RAM.
La preuve, essaie d'allouer un bloc de 20 ko. Tu réussiras (enfin, sauf si tu n'as pas 20ko de RAM), alors que la pile n'a qu'une capacité de 16ko.

OK au moins, c'est clair
merci

remarque avec malloc aussi et bien sur toutes les autres fonctions similaires :
-calloc
-realloc
-et d'autres que je connais pas

En fait, j'aurais préféré que ce soit sur la pile, parcequ'alors, je vois pas ou je bouffe 180ko de RAM , 16ko pour désarchiver le prog, un peu moins de 6ko pour les buffers d'écran+police de caractère), un handle pour faire un popup (je sais pas combien ça fait exactement, mais c'est pas énorme) et divers petit trucs qui dépassent pas 1ko au total. Et avec ça, pas moyen d'allouer un segment de 10ko environ

Poste ton code, p-ê que Kevin ou qq1 d'autre pourra t'éclairer

ben le prog est assez gros... c'est là : http://sciences-ti89.guilc.firstream.net/archives/comptac.zip
Le probleme arrive que quand j'ouvre des fichiers un peu gros, y a pas moyen de les ouvrir, le malloc échoue...
Si il y a une bonne ame qui veut bien m'aider, je le remercie d'avance

Les routiones d'allocation allouent sur une zone appelée le tas... "heap" en anglais...

j'ai pas encore regardé ton code mais:

si tu fais des petites allocations, utilise alloca.

J'ai un peu regardé alloca, mais ça ne peut pas me convenir a cause de ça :

The space allocated with alloca exists until the containing function returns (i.e. it will be automatically deallocated at the end of the function).

Je fais mes petites allocations (des chaines de caractères) dans des sous-fonctions, donc c'est pas interessant si ça me vide tout quand je quitte la fonction qui alloue la mem...
En tous cas, merci pour ton aide

sinon, tu ne peux pas passer par un fichier externe (c'est tres barbare ... mais rien que sur les chaines de caractères ca peut être interessant)

Le probleme des fichiers externes, c'est que c'est lent et lourd a utiliser...
Mes données sont dans un fichier externe, et justement, je les charge en RAM pour avoir mon tableau accessible facilement est rapidement.
Il y a toujours la possibilité de ne charger que la partie des données affichées, mais c'est le meme probleme, le scrolling va être ultra-lent après

aRf, je savais pas qu'il te falais de la rapidité ... pourquoi c'est aussi lent ? tu utilises des fonctions de tigcclib je pense

Non, pour l'affichage, j'ai repris la fonction de tthedit, c'est pour ça que j'ai une assez grosse zone memoire a allouer au début, il faut stocker les sprites de tous les caractères...
Niveau rapidité, c'est très satisfaisant pour afficher les donnés, mais si je lis direct a partir du fichier, là, ça va ramer, les temps d'acces aux donnés sont plus long...

ah oué ... bah pour palier à cela, n'utilise pas une routine de ce genre mais utilise directement l'adresse de la petite fonte et de la moyenne pour utiliser en suite des routines un peu moins rapides, tu va gagner 5*256+7*256 octets au minima

guilc: la dernière version des routines de font n'utilise plus de backbuffer, elle utilise directement les fonts, sur AMS 1.xx comme sur 2.xx.
Je peux te l'envoyer. De quelles polices as-tu besoin (F_4x6, F_6x8, F_8x10), et de quel type de routines d'affichage (A_NORMAL, A_XOR, A_REVERSE, A_REPLACE sont disponibles) ?
Pour l'instant, les routines de dessin sont toujours en C pour la plupart. Les versions ASM sont commencées, mais elles ne sont pas prêtes.

Et j'ai réécrit des routines de sprite d'ExtGraph. Le gain est de 30% sur les Sprite32_OR/XOR/AND, de 20% sur les Sprite8_OR/XOR (bench classique avec une double boucle, dessin sur chaque ligne, puis chaque colonne). Il faut que je fasse rapidement les Sprite8_AND et Sprite16_OR/XOR/AND.

20%, ce n'est pas trop mal, elles sont toujours en C, ou bien tu es un peu passé par l'asm ?

ben j'utilises la fonte F_4x6 en A_NORMAL seulement...
Je te remercie de me l'envoyer Xdanger
Mais je doute que ça règle totralement mon probleme...
M'enfin, c'est déja ça...

voué,c deja ca

jackiechan> je pense que c en asm tout de même .. koike la différence une fois la compilation faite ne doit pas êtree norme !

guilc> faut peut-être que tu refasses ton prog, enfin la structure, histoire de faire des allocations par bloc

ou bien tu es un peu passé par l'asm ?

Les routines ont été réécrites en ASM pur (j'aurais pu le préciser...). Elles sont toujours __attribute__((__stkparm__)), mais des versions __regparm__ sont prévues.

koike la différence une fois la compilation faite ne doit pas être enorme !

Bah, 30% plus rapide, c'est déjà pas mal, non ?
J'ai fait aussi des Sprite16: le gain n'est que de 9 à 10% car il n'est pas possible de gratter sur l'algorithme.

ben j'utilises la fonte F_4x6 en A_NORMAL seulement... Je te remercie de me l'envoyer Xdanger

De rien. J'ai ton e-mail, je te l'envoie rapidement.

XDanger > Merci, tout simplement

nEUrONe > ben niveau structuration du prog, je me suis fait chié a faire des allocations dynamiques de partout pour ne pas bouffer un brin de mémoire inutile... Au bilan, le code est bourré de realloc...

Mais j'ai un doute. Voila la structure qui peut poser probleme :
typedef struct {
char *tiers;
date d;
double montant;
char statut; // pointé ou non (1/0)
} operation;

Sachant que tiers est une chaine de caractères de maximum 80 caractères, je me demande si j'ai pas intérer a le faire en statique (char tiers[81]) plutot qu'en dynamique... Je perd de la place sur les chaines courtes, mais je gagne car je fais beaucoup moins de malloc (typiquement sur le fichier qui sature la mem : 150 malloc en moins)...

A votre avis, quelle est la meilleure solution ?

Au fait, la limite que tu rencontres est probablement le nombre maximal de handles (2000).

Ah !!! c'est vrai ! j'y avais pas pensé a celle la !
Je vais tester ça... PArceque ça m'étonne que ma structure prenne les 137ko de RAM qu'il me reste après l'allocation initiale des buffers + menu...

2000 handles max, mais un bon nombre sont déjà utilisé par le système.... plus un handle par variable...
ce qui signifie que, en pratique, il n'y a pas plus de 1700 handles libres, il me semble, non ?
(et encore, sur une calc moyennement remplie)

(il me semble que ct dans ces eaux là qd j'ai regardé voila bien longtemps)

Ben j'ai mis plein de choses en statique dans mes types, et ça regle rien...
Mais puisque tu dis que qu'il y en a 1 par var, squale, ben en fait mettre en statique change pas grand chose... SI je compte bien, en dynamique : un pointeur dans la structure + la zone de mémoire allouée = 2 handles, et en statique : 1 handle pour le tableau. Donc sur mon fichier, j'éconnomise seulement 150 handles . Et apparement, c pas suffisant pour corriger le probleme...

Tu utilises combien de handles au total ?
Je ne comprends pas ce que tu veux dire quand tu dis que tu mets des choses en statique ou en dynamique.

statique ou dynamique : changement du type de "tiers" dans la structure du post #20...
Je sais pas combien j'ai de handle au total, j'ai pas encore trouvé la fonction qui le donne dans la doc de TIGCC (fo peut-être la progammer)...
Mais certainement beaucoup, vu la complexité du truc. Je suis en train de chercher encore des détails dans cette direction...

Le nombre de handles que tu utilises = le nombre de fois où tu alloues de la mémoire (malloc, calloc, HeapAlloc, HeapAllocPtr, HeapAllocHigh, HeapAllocHighPtr, ...)

ben aparement, vu ce qu'a dis squale, il y a en plus un handle par variable dans le prog...
Donc ça fait beaucoup.
Si ne je compte que les allocations, dans la version dynamique, il y en a 3 + nb d'opérations + une boite de dialogue de temps en temps... Ce qui fait dans le fichier qui plante : 154 au max... donc c'est pas trop
Mais avec toutes les variables, alors c'est énorme

ça fait un handle par variable TIOS ! Pas par variable dans ta source C !