Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))
./REPRISE DU POST PRECEDENT (post n°19)   Marquer comme non lu.
LionelA Ecrit le: Vendredi 15 juillet 2005 à 14:50 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


non non :)
En fait c'est pour detecter le nombre de handles non libérés a l'interieur du programme durant la phase de developpement.
En fait quand le main quitte on peut vouloir que ca soit normal que le Exit libere un certain nombre de handles qui sont utilisés tout au long du prog (ca evite de mettre du code pour liberer ces handles) et donc il ne faut pas qu'ils soient detectés parmi les handles anormalement non libérés.
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°20   Marquer comme non lu.
Link Ecrit le: Vendredi 15 juillet 2005 à 15:52 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

Donc, ces NB_EXIT_HANDLES, c'est choisi par celui qui utilise la lib, non?
Parce qu'ils ne correspondent à aucune table...
L'utilisateur devrait donc définir NB_EXIT_HANDLES à une valeur qu'il aura trouvée en programmant, et la lib le préviendrait si à la fin il reste plus de handles non-libérés que la constante...

Mais si tu en libères un accidentellement et que tu oublies un leak, ce ne sera pas signalé, puisque les "exit handles" ne sont pas répertoriés... (ça pourrait être une bonne idée de les stocker dans une table à part ou de les marquer comme "exit handles" dans une table de flags?
    
./Post n°21   Marquer comme non lu.
LionelA Ecrit le: Vendredi 15 juillet 2005 à 16:07 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Oui en effet, mais pour liberer accidentellement faut le faire :p
Je pourrais faire une table des exit handles mais il faudrait rajouter une fonction pour les marquer, fonction qui n'existerai plus en mode "release" (i.e. DEV_PHASE == 0)
(Les valeurs qui sont données dans l'exemple sont celles de F-Zero et elle n'ont rien à voir avec cet exemple au fait)
Et c'est le programmeur qui determine toutes ces valeurs :
Pour F-zero j'ai 7 allocations permanentes :
- une par fichier ouvert (avec une fonction perso), 4 fichiers -> 4 handles
- une pour le Double Buffering de tigcc
- 2 pour les tables de mode7
J'ai donc mis NB_EXIT_HANDLES à 7 pour pas que ca me signale quand le prog les libere en fin de main.
Les autres constantes sont a ajuster aussi en fonction du nombre d'AI redirigées ou du nombre max de handle utilisés (et oui je redirige 5 AI en meme temps et j'ai un max de 27 handles a la fois)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°22   Marquer comme non lu.
Lionel Debroux Ecrit le: Samedi 16 juillet 2005 à 11:37 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> - une par fichier ouvert (avec une fonction perso), 4 fichiers -> 4 handles
> - une pour le Double Buffering de tigcc
Est-ce que ça ne pourrait pas être dans le même handle ?

Sur les programmes qui allouent beaucoup de handles petits, il est souvent très avantageux de regrouper toutes les allocations. Voir les readme de Ice Hockey 68k, TI-Chess, Pepzip...
Le problème de la fragmentation de la mémoire qui permettrait d'allouer plus de blocs plus petits mais pas moins de blocs plus gros est théorique.
Partant du principe de sage utilisation qui est qu'il faut toujours archiver autant de trucs que possible (de toute façon, si on ne le fait pas, beaucoup de programmes refusent de fonctionner), qui a déjà vu une série de blocs lockés disséminés dans toute la mémoire de sorte que la taille du plus gros handle utilisable soit inférieure à 20 KB ?
Lionel Debroux - membre de TICT.
    
./Post n°23   Marquer comme non lu.
Link Ecrit le: Samedi 16 juillet 2005 à 11:51 Déconnecté(e)    Voir le profil de Link Envoyer un email à Link Visiter le site WEB de Link Envoyer un message privé à Link  

Ben, je ne crois pas qu'on puisse regrouper plus: Il faut nécessairement un handle par fichier... (sauf s'il y a des buffers évidemment, là, il devrait être possible de regrouper lesdits buffers...
    
./Post n°24   Marquer comme non lu.
LionelA Ecrit le: Samedi 16 juillet 2005 à 14:34 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


ben en fait j'ai une fonction perso qui marche a la maniere de fopen (enfin j'imagine car je n'ai pas regardé le source de fopen mais bon) et qui donc alloue un bloc pour y stocker ma structure equivalente a FILE.
Je sais que ca serait mieux de faire qu'une seule allocation mais quand j'ai commencé le dev de F-Zero je n'avais jamais programmé serieusement sur TI (ni sur embarqué) donc j'ai appliqué les techniques d'allocation vu en cours (et les mallocs ca y va, c'est gratuit) donc voila.
Enfin vu que les 4 blocs sont alloués à la suite (dans le code) ils devraient pas etre trop eloignés les uns des autres dans la RAM, et donc ca ne doit pas trop fragmenter. Ca revient donc au même que si ils etaient alloués en une seule fois mis à part que j'utilise 4 fois plus de HANDLE (mais y'en a 2000 de dispo, c'est pas un drame). :)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°25   Marquer comme non lu.
Folco Ecrit le: Samedi 16 juillet 2005 à 15:08 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Tu devrais essayer de regrouper, j'ai gagné pas mal de place en le faisant (et en passant par une section BSS également, ça évite des allocations/vérifications/exit/désallocation à la main).
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°26   Marquer comme non lu.
LionelA Ecrit le: Samedi 16 juillet 2005 à 15:15 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


Vu comment c'est codé avec les pieds je prefere laisser comme c'est sinon ca remet trop de code en cause.
Et puis je n'ai que allocation a faire car verification/desaloc/exit se fait automatiquement avec le manager de memoire etc..
Et enfin j'ai besoin a un endroit du code de faire beaucoup de petits malloc pour le calcul de placement de waypoints sur la piste (avec orientation des portions de la route et tout) donc voila :)

-Edité le Samedi 16 juillet 2005 à 15:15 par LionelA-
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°27   Marquer comme non lu.
Folco Ecrit le: Samedi 16 juillet 2005 à 15:41 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


tous tes petits malloc pourraient se réduire à un gros si tu regardes avant la place dont tu dois disposer non? %)
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°28   Marquer comme non lu.
LionelA Ecrit le: Samedi 16 juillet 2005 à 15:49 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


non, je ne connais pas a l'avance l'agencement des map : nombre de croisements etc... je me suis tellement arraché de cheveux en faisant cet algo que j'y toucherai plus jamais je pense :s
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°29   Marquer comme non lu.
Folco Ecrit le: Samedi 16 juillet 2005 à 16:33 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


oui, je me souviens des topics là-dessus ^^
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°30   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 16 juillet 2005 à 16:47 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


LionelA :
non, je ne connais pas a l'avance l'agencement des map : nombre de croisements etc... je me suis tellement arraché de cheveux en faisant cet algo que j'y toucherai plus jamais je pense :s

Tu peux toujours connaître en faisant 2 passes, une pour calculer la mémoire nécessaire (ou une bonne borne supérieure pour la mémoire nécessaire) et une pour faire les vrais calculs. Les routines d'exportation de ld-tigcc fonctionnent comme ça, par exemple: on fait une fois le tour de toutes les structures de données à exporter pour calculer la taille (et elle doit être précise à l'octet, une borne supérieure ne suffit même pas dans ce cas) et une deuxième fois pour exporter vraiment. Les versions récentes de AutoClBr fonctionnent comme ça aussi.

Une autre solution est de faire des réallocations au fur et à mesure. Les premières versions de AutoClBr faisaient ça (une réallocation de la ligne d'entrée pour chaque parenthèse rajoutée).
-Edité le Samedi 16 juillet 2005 à 16:48 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°31   Marquer comme non lu.
LionelA Ecrit le: Samedi 16 juillet 2005 à 16:55 Déconnecté(e)    Voir le profil de LionelA Envoyer un email à LionelA Visiter le site WEB de LionelA Envoyer un message privé à LionelA  


y'a moyen de faire ca en effet mais ca prendrait 2x plus de temps (meme si je sais que c'est pas les "loading..." pendant 10s qui te font peur :)) Je ne crois pas que le gain en taille du programme (ou d'ailleurs perte) en vaille la peine par rapport a une utilisation abusive d'allocations. (Et puis j'ai vraiment plus envie de toucher à cette partie que j'ai testé a mort et qui ne doit plus contenir de bugs)
Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/
    
./Post n°32   Marquer comme non lu.
Lionel Debroux Ecrit le: Dimanche 17 juillet 2005 à 09:34 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> Tu devrais essayer de regrouper, j'ai gagné pas mal de place en le faisant
C'est évident.
> (et en passant par une section BSS également,
C'est beaucoup plus rare. Kevin cite toujours CC comme étant amélioré en taille par l'utilisation de BSS, ce qui veut surtout dire que CC est codé avec les pieds: il y a des blocs de mémoire assez gros, qui devraient plutôt être gérés à la main.
Il y a au moins 1 KB de BSS dans TI-Chess (au moins 600 octets si je me souviens bien dans opening.c que j'ai modifié récemment, et il y en a ailleurs), et pourtant, le programme se porte mieux après passage à -mno-bss: taille décompressée peu changée, taille compressée réduite...
> ça évite des allocations/vérifications/exit/désallocation à la main).
Mais (en AMS native) nécessite tout un stub de démarrage pour remplir les références xxx.l relogées (au lieu des d(pc) / d(an) utilisables en -mno-bss)...

GCC ne le faisant pas tout seul, il est souvent très intéressant d'utiliser des pointeurs auxiliaires. Sur TI-Chess, opening.c, j'ai gagné plus de 100 octets (l'ancienne version est commentée).
Lionel Debroux - membre de TICT.
    
  :: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))
Pages : 2/2     « 1 [2] » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 59.54ms avec 18 requetes