TIGCCLIB: Bug dans stdio ??? - Page 1

Bon voila je voulait savoir ou en etait mon simulateur de 6502 en ASM pour pouvoir vérifier que tout marche correctement. je me suis donc dit que j'allait utiliser puts pour afficher l'instruction qu'il allait executait. Tout fonctionne bien jusqu'au moment ou j'ai droit a une erreur tibasic : "Memory Error" !

Pourtant sans l'utilisation de puts tout fonctionne bien !

Je me dit ptet que puts est buggé, et j'essaye printf, et la pareil !

Je me demande si il n'y aurait pas un problème dans la gestion de la "console" dans stdio.h de TIGCC

Je pose cette question ici avant d'essayer d'avertir plus loin pour savoir si je suis le seul a avoir se pbm ou si c'est bien un pbm reel. (je vais tester un truc d'ici la)

pour info mon code est en ASM (mais bon sa change rien a priori)
je vais faire quelques test plus simple en C et asm pour voir si sa marche ou pas...

Je sais que printf utilise une mémoire tampon donc peut être que la mémoire tampon de cette fonction est saturé ou encore peut être que tu vide la pile.

normalement je ne touche pas a a6 ni a7 donc de se coté il ne devrait pas y avoir de pbm, mais j'ai remarqué qu'avec puts/printf il y a des fois ou il me pete se genre d'erreur apres avoir affiché un tres grand nombre de caracteres.. a priori mon code n'est pas en cause puisqu'il fonctionne sans pbm quand puts/printf nest pas utilisé...

t'as les mêmes problemes avec un code en C ??

justement j'allait tester.. et a priori non....

je vais retester avec un prog simple en asm

Essaie peut-être d'utiliser printf_xy, ça prendra moins de place et tu ne devrais pas avoir de problème. Fais cependant attention, je crois que la chaîne déclarée pour contenir le texte qui sera affiché est de 100 caractères. Donc ça peut planter avec des erreurs très bizarres si tu veux afficher trop à la fois.

le pbm c'est que je cherche a avoir le défilement type console et mes chaines de caractere (avec le caractere nul) ne dépassent pas 5cars

Brunni> printf_xy est une macro, donc il est impossible de l'utiliser en ASM, de plus, c'est une macro assez sale.

Sale, faut pas aller jusque là, de toute facon, c'est le meilleur moyen de la faire comme elle est implantée là ... je ne vois pas comment faire autrement pour que ca bouffe moins de place.

C'est très sale parce que le buffer est de taille fixe. printf n'utilise pas un buffer, mais un callback pour l'affichage.

Bah oué, mais on fait tous comme ca pour faire des printf_xy .. c'est vachement plus simple !

C'est très sale parce que le buffer est de taille fixe. printf n'utilise pas un buffer, mais un callback pour l'affichage.

Je serais très intéressé de savoir comment tu peux faire ça... Tu peux savoir à l'avance combien de caractères devra faire un buffer? Ou bien tu fais un "realloc" dans la routine sprintf?
PS: Je ne sais pas grand chose sur les callbacks, et j'ai beaucoup de peine à comprendre la doc en anglais.

Je peux t'assurer que les Callbacks m'interesse énormément mais je ne comprend pas grand choses.

le principe est simple, tu passes en argument à une fonction fn1 la pointeur d'une fonction fn2, ce qui permet à fn1 d'appeler fn2, sans la connaitre à l'avance.


c pratique par exemple pour des fonctions de tri :
tu fais une fonction générique qui accepte en argument deux pointeurs de fonctions : l'une qui permet de swapper deux elements, et l'autre qui permet de les comparer.


PS : à ce propos, je ne comprend pas pkoi dans tigcc, la fonction de tri n'accepte qu'un pointeur sur une fonction de comparaison... C'est franchement dommage !!
(D'apres ce que g compris, c une fonction std, mais ça serait cool de rajouter la version avec les 2 pointeurs de fonction, ça prendrait pas longtemps du tout !)

nEUrOO
: Bah oué, mais on fait tous comme ca pour faire des printf_xy .. c'est vachement plus simple !

Et ça bogue grave quand la chaîne est trop longue!

Pen^2
: PS : à ce propos, je ne comprend pas pkoi dans tigcc, la fonction de tri n'accepte qu'un pointeur sur une fonction de comparaison... C'est franchement dommage !!

Parce que c'est comme ça que fonctionne qsort. Et je ne vois pas l'intérêt d'une fonction de swapping. On donne la taille des éléments à qsort, ça suffit.

Oué, c sur ...

Kevin

Pen^2
: PS : à ce propos, je ne comprend pas pkoi dans tigcc, la fonction de tri n'accepte qu'un pointeur sur une fonction de comparaison... C'est franchement dommage !!

Parce que c'est comme ça que fonctionne qsort. Et je ne vois pas l'intérêt d'une fonction de swapping. On donne la taille des éléments à qsort, ça suffit.

non, ça ne suffit pas :
imagine par exemple une liste chainée de structures. Pour faire le tri vaut quand meme mieux changer les pointeurs qui servent pour le chainage qu'échanger toutes les données des structures qui peuvent etre assez volumineuses, non ?
Et c pas la peine de dire qu'une liste chainée n'est pas adaptée à une TI, je ne vois VRAIMENT PAS pourquoi !
si on programme proprement y'a aucun probleme

C'est vrai qu'en le programmant bien, avec du realloc, échange de pointeur, ca pourrait être sympa

une liste chainée dans un tableau, sinon
(au lieu de chainer des blocs mémoire, tu chaine des cases du tableau )
le seul inconvénient, c'est que tu dois allouer un tableau de taille fixe.
mais si tu sais combien d'éléments au max ta liste contiendra, c jouable

Les listes chainees ne sont pas la bonne representation pour un tri.

C'est faux. Il existe des algos de tris parfaitement adaptes pour les listes chaines.

oui, heureusement

Mais c'est moins efficace qu'avec un tableau de pointeurs.

Il peut arriver que certaines données soient plus pratiques à manipuler en les représentant par des listes chainées.

./24> bah, listes chainées, c aussi rapide que tableau (enfin, presque) pour le parcours... et c instantané pr les insertions et suppression, qd meme

le tri d'une liste chainé pour des donnée complexe peut etre largement plus rapide aussi

Non, le tableau de pointeurs est plus efficace.

Oui et non, un tableau c'est bien pour des donnée statique, ne changeant pas souvent, mais dans tout les cas avec un tableau de pointeur, cela prend autent de place qu'avec une liste chainé car il faut sauver un pointeur et la donnée dans les deux cas, et l'empreinte mémoire est quasi identique. La seule différence c'est qu'un tableau de pointeur est largement moins dynamique qu'une liste chainée, car l'insertion/suppression dans un tableau de pointeur est beaucoup moins aisé qu'avec une LC.

Il est vrai que mon affirmation en #26 serait plus juste en remplacant "liste chainé" par "donnée pointé par un pointeur" (un peu redondant..)

N'empeche que les LC sont dans beaucoup de cas plus adapté que les tableau et/ou tableau de pointeurs.

Je pense que les listes chaînées peuvent être intéressantes dans un certain nombre de cas. Notamment pour trier un gros tableau de données de grande taille (je pense à un tableau de ASAP_COUNT de structures de 1 short + 1 tableau de 64 char - c'est ce qu'il faut que je trie pour tthdex, cette partie-là est mise en veilleuse pour le moment).