Allocation dynamique de structure (et plantage de calto) - Page 1

Salut

Je continue mais divers problème de structure avec cette fois ci leurs allocation dynamique: l' erreur que j' obtiens est assez viscieuse => lorsque j' execute mon programme sous TIemu, aucun problème, l' allocation dynamique de structure se passe sans aucun problème.
Mais quand j' essaye d'executer le programme sous TI 89, dès que j' essaye de reallouez (realloc) l'espace pour ma structure, le programme RAME, et après le programme j' obtiens le message BUSY m' obligeant à faire un reset de la RAM de ma calto....
Mon code étant assez consequant et ne voyant pas du tout l' erreur que j' ai pu faire je mets une archive: http://membres.lycos.fr/nanarduff/fly.tar.gz


Merci d' avnce

hmm... ton code est assez obscur, mais tu as l'air de realloc ton tableau à chaque fois que l'on tire ? realloc est très lent, tu dois limiter au maximum son utilisation.

mais c'est difficile de comprendre la logique de ton programme, vu que tu utilises plein de variables globales au nom pas toujours très explicite, et qu'il n'y a absolument aucun commentaire.
si possible, diminue au maximum l'utilisation des variables globales (idéalement : n'en utilise qu'une seule, voire aucune). en plus du problème de lisibilité, il faut savoir que sur Ti les variables globales sont enregistrées dans le binaire directement, autrement dit ton tableau de char [LCD_SIZE] augmente la taille de ton .89z de 3840 octets, soit ... beaucoup

si le tableau est mis dans un segment BSS il ne prendra pas autant ^^
(tigcc fait ca tout seul si on lui dit)

un jour faudra que je d/l une version de TIGCC un peu plus récente que celle que j'avais quand j'ai arrêté moi ...

bon, alors si ça a été amélioré depuis, tant mieux; mais quoi qu'il en soit ce n'est toujours pas une bonne idée d'utiliser autant de variables globales, qu'elles prennent de la place en plus ou pas ^^

typiquement tu peux laisser l"adresse de ton ecran virtuel en global

Ok, mais our les variables globales je n' utilise "que" pour l' instant:
la variable quit => remplacé par une fonction shutdown{ quit = 1; } dans main.c (mais néanmoins en globale dans main.c ....)
les sprites => bien obligé de les utiliser en globales ! (ou sinon comment faire ?)
structure du vaisseau => mis en globale dans app.h
variable de la taille de la structure des munitions et structure => obligatoirement en globale car dans app.c et game.c

Et pour le realloc heuh en fait alors comment fait-on habituellement pour avoir n structures sans connaitre n ? J' ai beau chercher mais la seule manière que je trouve est l' allocation dynamique...

pour avoir n structures sans connaitre n ?

C'est ca que tu veux savoir?

typedef struct{
  //des trucs
} maStructure;

void main(void)
{
  unsigned short n = trouverN();
  maStructure *tableau = malloc(n*sizeof(maStructure)); // alloue un tableau de n structures de type maStructure
  memset(tableau,0,n*sizeof(maStructure)); // la remplir de 0

  //faire des choses avec tableau[i] par exemple

  free(tableau);
}

pour le sprites : oui bien sûr ca ne peut être en global, mais généralement on ne les compte pas dans les variables globales

si tu as tant besoin que ca de variables globales c'est que tu as mal pensé la structuer de ton programme
et tu peux aussi passer des arguments aux fonctions et utiliser leur valeurs de retour

Nanar_duff :
avoir n structures sans connaitre n

même si n varie tu peux quand même avoir une estimation de son maximum m et il te suffit d'allouer m structures.
apres c'est à toi de faire en sorte que ca maximum ne soit jamais dépassé (sinon plantage !)

Ok. Après avoir reflchi à une limite de structure: c' est en effet une solution car le temps que le premier missile disparaisse de l' écran, qui lui n' est pas variable, un nombre maximum de missile seront lancé. Mais hum je n' ai quand meme pas trop envie de prendre le risque de refaire planter ma calto une 2eme fois donc y aurait-il un moyen plus fiable que l' emulateur pour tester unprogramme ?

Si tu utilise VTI, tu peux essayer TiEmu qui simule mieux en ce qui concerne la vitesse d'éxecution. (pour l'instant j'ai pas vu de différence entre TiEmu et onCalc).

Ok, je n' utilise que TiEmu car il s' agit d' un des rares emulateurs sosu Linux. (du moins le seul que je connaisse.)

Les BSS n'améliorent que les programmes mal écrits (par exemple CC): pour faire comme il faut, les allocations doivent être faites à la main, comme on fait depuis des années en AMS native...

Comment on dit à TIGCC de rendre dynamique une variable globale ?

On ne dit pas à tigcc de le faire, on le programme soit meme généralement en utilisant un pointeur global qui pointe vers une zone mémoire alouée.

je pense qu'il voulait savoir comment on dit a tigcc de mettre telle variable en bss plutôt
a mon avis il suffit de ne pas l'initialiser dans la declaration et de ne pas mettre -mno-bss dans les options de compilation (à verifier)

Ah ok ! Et pourquoi les variables globales non-initialisées ne sont-elles pas BSS par défaut ?

Elle le sont.

#16: ... maintenant (TIGCC 0.95+). Même si ça se rapproche du comportement standard des programmes sur d'autres plate-formes, sur la nôtre, ça casse la compatibilité antérieure, pour un résultat qui est en pratique, il faut bien le dire, souvent pire.
Les programmes n'utilisant que quelques dizaines d'octets de globals non initialisés (= les programmes bien écrits, le reste s'allouant à la main) bénéficient souvent souvent de -DMERGE_BSS ou -mno-bss, par le passage de références xxx.l relogées à des références d(pc) non relogées (au moins en lecture - en écriture, il faut utiliser -mpcrel si le programme n'est pas trop gros, -freg-relative-an sinon). ~2 KB sur Ice Hockey 68k, par exemple.
Au passage: au niveau de l'allocation mémoire à la main, pour plus d'efficacité, il faut les compacter. Plusieurs centaines d'octets sur TI-Chess, Pepzip, etc. C'est plus sensible à la fragmentation, Kevin et PpHd le disent souvent, mais je n'ai jamais vu le problème, et en pratique, si la calculette n'est pas capable d'allouer des blocs d'une vingtaine à une trentaine de KB, ça veut dire qu'elle n'est pas non plus capable de tourner les gros programmes => reset !

(Certes, je me répète, mais les autres aussi - les BSS, en pratique, sont en général une connerie, et il faut que ça se sache ! Ca ne va pas durer, vu que c'est écrit - en anglais - dans S1P9)

En fait il faudrait rendre dynamique uniquement les variables globales les plus grosses (tableaux...). Qu'en penses-tu ?

C'est ce que fait Ice Hockey 68k, entre autres. TI-Chess le fait dans une moindre mesure, il reste de gros globals non initialisés mergés dans la section data.

Ok, mais je te posais la question à propos de TIGCC Il ne mettrait en BSS que les variables les plus grosses.