Mon second programme en C - Page 8

Et maintenant, au lieu de 0 relogements, j'en ai 33 !!!

Ca doit être des accès en écriture... à moins qu'il y ait aussi des accès en lecture parce que la structure est en .bss.
Est-ce que tu as, dans les options de ton TIGCC Project (si tu en utilises un) ou sinon avec -DMERGE_BSS, désactivé les BSS ?

Oui, il m'a créé 48 bytes de BSS. Saloperie ce truc, faut être magicien pour que ce putain de compilateur arrête d'en faire à sa tête.

Sally -> je passais des pointeurs en paramètres, là je veux juste utiliser une variable globale au programme. Que chaque routine y accède en pc-relatif quoi.

Je comprends pas pourquoi cet abruti est pas capable d'écrire des offset(an), et se croit obligé de faire des relogements pour le fun. En fait, en C, tu gagnes 75% de vitesse en codant, puis tu perds 300% à tout recommencer à cause des conneries du compilo.

tu passes les bonnes options au compilateur ? si tu ne veux pas de bss il ne suffit pas de mettre -mno-bss ? si tu veux du code pc-relatif il ne suffit pas de mettre -mpcrel ?

Je comprends pas pourquoi cet abruti est pas capable d'écrire des offset(an)

Parce que tu ne lui as probablement pas dit de le faire
Pour ça, il faut mettre -freg-relative-a4 ou -freg-relative-a5 dans les options du compilo, ou explicitement utiliser une global register variable

si tu veux du code pc-relatif il ne suffit pas de mettre -mpcrel ?

Pour les accès en lecture (<ea> source), si (du moins, si le programme n'est pas trop gros).
Pour les accès en écriture, non, parce que Motorola a décidé que les adressages pc-relatifs n'étaient pas utilisables en <ea> destination (#ouinbouh#).

(à la fois, paye ta structure de bourrin, si elle était déclarée en locale et passée en paramètre intelligemment (mon dieu, je suis d'accord avec Kevin ) t'aurais peut-être moins de problèmes )

En effet, mais ça serait moins optimisé
(pour un gain en maintenabilité pas évident à mon avis)

Bah quand même, ça permet de savoir exactement qui utilise quoi, et quand.

Brunni (./9) :
Pour le type bool tu peux écrire un truc du genre:
typedef enum {false=0, true=1} bool;
Mais ce n'est pas forcément optimal étant donné qu'on ne sait pas la taille que le compilo réservera à l'enum. Donc ça peut très bien être 32 bits, à vérifier avec sizeof(bool). Sinon une autre solution:

typedef unsigned char bool;
enum {false=0, true=1};

Ainsi en déclarant un bool tu déclares en fait un unsigned char (8 bits) et ensuite tu utilises des constantes de l'énumération que tu définis après.
Concernant le warning je n'étais pas au courant, ça fait longtemps que je n'ai plus codé sur TI

Et si tu est en C99 tu oublie ce genre de bidouilles : http://en.wikipedia.org/wiki/Boolean_datatype#C99


Sinon Martial, si tu veux vraiment faire du C oublie les bidouilles de l'ASM, faire du C comme si tu faisait de l'ASM est une mauvaise pratique...


edit:Hum j'ai comme qui dirais raté quelques pages

Ximoon (./216) :
(à la fois, paye ta structure de bourrin, si elle était déclarée en locale et passée en paramètre intelligemment (mon dieu, je suis d'accord avec Kevin ) t'aurais peut-être moins de problèmes )

Ben quoi... c'est qu'une suite de dc.w/dc.l ... des variables dans des sections de code, je vois pas le souci... oui, j'ai besoin de tant de variables et alors ?
Quant au fait de passer ça en paramètre intelligemment, si je poste, c'est précisément pour avoir des conseils à ce niveau figure-toi Ya suffisamment ici de poids lourds en programmation pour m'aider me semble-t-il ?

Lionel Debroux (./217) :
En effet, mais ça serait moins optimisé

C'est bien ça le problème ...

Godzil (./219) :
Sinon Martial, si tu veux vraiment faire du C oublie les bidouilles de l'ASM, faire du C comme si tu faisait de l'ASM est une mauvaise pratique...

Ben je vois pas le problème à avoir des variables dans les sections de code, vu qu'on peut pas faire autrement... et encore moins à les adresser en pc-relatif, c'est le mieux optimisé... Quant à la lecture/écriture en TAG_INTELLIGIBLE(an), je vois pas ce que ça a de pas maintenable justement, ça l'est autrement plus que de se déplacer dans un groupe de variable par in/décrémentation de pointeur.

Puis tu veux que je fasse du C comment ? Comme en basic ? Désolé, l'asm est ma seule base, ou plutôt le fonctionnement du proc, et je sais ce que je veux lui faire faire. Evidemment, lui dire, c'est une autre paire de manches.

d'un autre côté, quand tu codes en C (et c'est encore plus vrai pour des langages plus "haut niveau"), c'est généralement plus pour gagner du temps au moment du développement et faciliter la maintenance que pour compter les cycles CPU...

les optimisations du style "omg ça me coute 2 cycles CPU de plus que si je rendais mon code imbitable", ça va pour quelque chose comme peut-être 5% (et encore) de ton programme, qui ont vraiment besoin à mort de vitesse... Mais pour le reste, si tu gagne une semaine par mois à coder, tant pis si c'est 10% plus lent ^^

Folco (./220) :
Désolé, l'asm est ma seule base, ou plutôt le fonctionnement du proc, et je sais ce que je veux lui faire faire

Le problème est peut-être là
tu penses plus à ce que tu veux que le CPU fasse... Et non à ce que tu veux que ton programme fasse ; alors que finalement, le CPU, globalement, l'utilisateur en a RAF, tant que le programme répond à ses besoins ^^

Je ne dis pas que connaitre le fonctionnement du CPU et de la machine en détails soit une mauvaise chose (ça permet d'éviter de faire complètement n'importe quoi aussi, et sur une machine limitée comme celle-ci, c'est une très bonne chose), mais est-ce nécessaire de se focaliser là-dessus à tout prix ?

Ça va venir avec la pratique ça je pense...

c'est sûr
allez, un peu de détente dans ce monde de brutes, sans perdre de vue le codage:

http://xkcd.com/571/

Sasume > Certes ^^
(ça fait drole de voir quelqu'un qui se met au C en ayant pas mal d'expérience et d'habitudes issues de l'ASM, je suppose ^^ -- ou ça fait drole de voir quelqu'un qui se met au C tout court )

squalyl > Et pourquoi pas http://xkcd.com/303/ ?
(ça me manque, ça, depuis que je passe mes journées à faire du PHP ^^ )

squale92 (./221) :
d'un autre côté, quand tu codes en C (et c'est encore plus vrai pour des langages plus "haut niveau"), c'est généralement plus pour gagner du temps au moment du développement et faciliter la maintenance que pour compter les cycles CPU...

les optimisations du style "omg ça me coute 2 cycles CPU de plus que si je rendais mon code imbitable", ça va pour quelque chose comme peut-être 5% (et encore) de ton programme, qui ont vraiment besoin à mort de vitesse... Mais pour le reste, si tu gagne une semaine par mois à coder, tant pis si c'est 10% plus lent ^^

Folco (./220) :
Désolé, l'asm est ma seule base, ou plutôt le fonctionnement du proc, et je sais ce que je veux lui faire faire

Le problème est peut-être là
tu penses plus à ce que tu veux que le CPU fasse... Et non à ce que tu veux que ton programme fasse ; alors que finalement, le CPU, globalement, l'utilisateur en a RAF, tant que le programme répond à ses besoins ^^

Je ne dis pas que connaitre le fonctionnement du CPU et de la machine en détails soit une mauvaise chose (ça permet d'éviter de faire complètement n'importe quoi aussi, et sur une machine limitée comme celle-ci, c'est une très bonne chose), mais est-ce nécessaire de se focaliser là-dessus à tout prix ?

... ou comment me donner l'envie de refoncer dans l'assembleur (bientôt 8 ans de pratique... je vais pas oublier comme ça )

désolé

Ben de toute façon, si le but de Martial est "les perfs avant tout", le C sur une plateforme comme la TI-89 va le décevoir

Après, rien n'empêche de mixer les deux hein, on peut très bien faire les opérations critiques d'un jeu en ASM, et la logique casse-pieds à écrire (mais qui n'a pas besoin d'être aussi optimisée) en C.

Ben non justement, je me disais qu'apprendre le C sur une telle plateforme permettait de savoir faire du C tout en regardanr un poil côté machine, juste de quoi produire un code efficace, mais sans plus. Je ne cherche pas le state of the art dans le code généré, mais le jour où je pondrai un code de 2,5 ko avec 33 relogements, ça voudra dire que je serai plus que centenaire et sénile ^^

Bon, dans les options de l'IDE, en mergeant les BSS avec les sections de code données, il ne me reste plus de BSS et que 4 reloegments. Ca pourrait venir d'où ? Comment les dégager ? Par principe, j'aime bien le code intégralement PIC...

Ok vu, j'ai deux fois ça grosso-modo :

	DrawingData.Curs.x0 = DrawingData.Curs.x1;
	DrawingData.Curs.x1 = TmpX0;

Mes 4 relogements viennent de là... Comment les éviter ? En plus, en mergeant les BSS et les sections de code, j'ai gagné pas loin de 200 octets sur 2,5 ko de code ! (c'est fou ce que la taille augmente vite en C, et ce sans la moindre donnée, que du code )

Folco (./228) :
Ben non justement, je me disais qu'apprendre le C sur une telle plateforme permettait de savoir faire du C tout en regardanr un poil côté machine, juste de quoi produire un code efficace, mais sans plus. Je ne cherche pas le state of the art dans le code généré, mais le jour où je pondrai un code de 2,5 ko avec 33 relogements, ça voudra dire que je serai plus que centenaire et sénile ^^

Dans ce cas, fait de l'ASM, faire du C "optimisé" pour une machine revient à faire de l'ASM et pas du C, surtout du C "portable"

---

./230: 200 Octets ? c'est ridicule

il est pas alloué au runtime le BSS? je vois pas comment il peut prendre de la place

enfin, bon, mon avis c'est que t'optimises tellement en asm que t'as du mal avec le C parce que t'arrives pas à faire exactement la même chose qu'avant. mais c'est le prix de la portabilité, et c'est pas forcément pire en termes de performances.

en plus, as tu vraiment besoin d'éviter les relogements? C'est pas juste une méga contrainte que tu te poses, d'avoir du code PI?

il est pas alloué au runtime le BSS?

Si

je vois pas comment il peut prendre de la place

D'une part dans le code qui alloue et désalloue le BSS (qui, dans les programmes AMS native, est embarqué dans le programme), et d'autre part dans les relocations: les références aux BSS sont des xxx.l directs, qui doivent être relogés au runtime selon l'emplacement en mémoire du BSS.
C'est pour ça que le BSS, en général, sux size-wise.

Ximoon (./218) :
Bah quand même, ça permet de savoir exactement qui utilise quoi, et quand.

+1, c'est clair.

les programmes où tout est global et toutes les fonctions peuvent trafiquer tout.

Folco (./220) :
Ben je vois pas le problème à avoir des variables dans les sections de code, vu qu'on peut pas faire autrement...

Euh si, il y a la pile aussi... Et le heap (cf. BSS). Et les variables de données externes.

Le gros problème des variables stockées à l'intérieur du programme, c'est qu'elles gardent leur valeur si le programme n'est ni archivé ni compressé et que donc le programme risque de foirer si on ne les initialise pas soigneusement au début de _main (et non pas dans l'initialisateur lors de la déclaration).

Folco (./229) :
Bon, dans les options de l'IDE, en mergeant les BSS avec les sections de code données, il ne me reste plus de BSS et que 4 reloegments. Ca pourrait venir d'où ?

Écritures dans ta structure globale.

Comment les dégager ? Par principe, j'aime bien le code intégralement PIC...

-mpcrel
Attention, taille du programme limitée à 32 KO si tu utilises ça.
Et il y a des relogements dans TIGCCLIB par endroits.

lionel > ah ok c'est les relogements qui prennent de la place, ok.

d'ou l'idée je suppose de référencer tous les bss par rapport a l'adresse de base de la section, comme ça on a un seul relogement non?

Godzil (./231) :
Dans ce cas, fait de l'ASM, faire du C "optimisé" pour une machine revient à faire de l'ASM et pas du C, surtout du C "portable"

je me fous de la portabilité, et je veux apprendre le C. C'est interdit ?

Godzil (./231) :
./230: 200 Octets ? c'est ridicule

Mais putain Godzil, t'as beau taper sur Kevin t'es de la même intransigeance vis-à-vis des autres ! Je suis pas en entreprise, j'ai pas de patron, ni de client, ni aucune obligation. Je me pose un but : "Je veux arriver à un programme qui ressemble à ça", != "Je veux faire un programme qui marche je sais pas trop comment". C'est interdit ?

squalyl (./232) :
mais c'est le prix de la portabilité

mais où, où ai-je donc mis ma pelle à tarte ?

squalyl (./232) :
en plus, as tu vraiment besoin d'éviter les relogements? C'est pas juste une méga contrainte que tu te poses, d'avoir du code PI?

-> la beauté du truc. Et c'est toujours plus petit en taille d'éviter les relogements. Et ça me fait marrer de voir les nostubistes que les relogements ne dérangent pas La majorité de mes programmes pourraient se lancer sans AMS si je viraient les stubs kernel, la majorité des programmes nostub en seraient infoutus.

Kevin Kofler (./234) :
les programmes où tout est global et toutes les fonctions peuvent trafiquer tout.

C'est sûr. Faut choisir entre optimisation et "qualité" (?). On est habitué avec toi, t'inquiète.

Kevin Kofler (./234) :
Le gros problème des variables stockées à l'intérieur du programme, c'est qu'elles gardent leur valeur si le programme n'est ni archivé ni compressé et que donc le programme risque de foirer si on ne les initialise pas soigneusement au début de _main (et non pas dans l'initialisateur lors de la déclaration).

On est d'accord, mais pour la majorité des variables, je m'en fous.

Kevin Kofler (./234) :
Écritures dans ta structure globale.

Tu veux dire quoi précisément ? Il est infoutu d'utiliser offset(an) pour ça ?? Pourquoi c'est pas fait par défaut, toi qui est toujours pour l'optimisation taille ?

Kevin Kofler (./234) :
Attention, taille du programme limitée à 32 KO si tu utilises ça.

Sans blague

d'ou l'idée je suppose de référencer tous les bss par rapport a l'adresse de base de la section, comme ça on a un seul relogement non?

-freg-relative-an référence .data et .text par rapport à __ld_entry_point_plus_0x8000, mais pas la section BSS (il me semble que dans ce cas, la section BSS n'est pas supportée: il faut s'en passer d'une façon ou d'une autre).
Je ne crois pas que la possibilité de ne référencer que la section BSS par rapport à un registre soit automatiquement implémentée par TIGCC/GCC4TI.

Il est infoutu d'utiliser offset(an) pour ça ??

Si tu ne lui demandes pas, oui, il en est infoutu. Voir ./215

Pourquoi c'est pas fait par défaut, toi qui est toujours pour l'optimisation taille ?

Dans TIGCC/GCC4TI, beaucoup de choses ne sont pas faites par défaut parce qu'elles ne respectent pas le comportement du standard C, ou ne sont pas applicables à tous les programmes tout en maintenant la correction du programme. Ici, c'est (au moins !) la deuxième raison: tu ne peux pas passer brutalement (par simple changement d'options de compilation) des adressages pc-relatifs / xxx.l aux adressages d(an), à cause des handlers d'interruption et d'exception.

RAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHH
Je compile avec -mpcrel :
"Symbol 'DrawingData' too far for size 2 reloc at 0x694".
Je croyais que ça arrivait qu'en assembleur, quand on faisait des adressages courts qui marchaient pas.... YAAAAAY NON !!!! même en C, langage de haut niveau, tu te tapes ce genre de merdes ! qu'on vienne pas me dire que c'est loin de la machine et très portable cette merde, il est même pas foutu de compiler en sachant ce que fait le proc derrière. t1 entre les bugs ou les problèmes de design du compilateur, j'hésite pas mal, mais c'est quand même pas super fûté comme soft

./238: ça doit être un accès à un BSS (xxx.l) sur deux octets, ce qui peut être déclenché par une combinaison invalide / non supportée d'options de compilation / link (auquel cas, c'est PEBKAC, pas un bug / problème de design des outils )

Poste-nous la façon dont DrawingData est déclaré, ainsi que les options du compilo, du linker, de l'assembleur et les options (Project -> Options) ayant trait aux BSS

Ben quand on commence par dire qu'on va assembler un programme mieux qu'un humain, ça fait très con d'écrire un adressage qui n'existe pas je trouve...