GTC : un TIGCC sur votre calculatrice ? - Page 11

c ce que je lui dit depuis hier, mais il veut pas me croire. Il continus à se battre ensemble

Pour avoir des différences de taille assez importantes, est-ce que GTC ferait par défaut des optimisations qui font gagner beaucoup de place, que GCC ne ferait pas ? Je sais que GCC n'est pas toujours fin (c'est d'ailleurs pour ça que j'utilise aussi largement l'ASM inline avec opérandes C dans tthdex), mais il n'est pas sûr que cela suffise à expliquer toute la différence.

Par optimisations qui font gagner beaucoup de place, que GCC (ou peut-être que c'est le linker, pas le compilateur) ne fait pas par défaut, il y a les conversions lea xxx.l,an, jsr xxx.l -> lea d(pc),an, jsr d(pc)/bsr. jsr xxx.l prend 6 octets + 4 octets pour la relocation, jsr d(pc) et bsr en prennent 4. Pourtant, ces conversions sont parfaitement licites, font gagner de la place et du temps, s'il y a moins de 32 KO de différence...

XDanger
a écrit : Pour avoir des différences de taille assez importantes, est-ce que GTC ferait par défaut des optimisations qui font gagner beaucoup de place, que GCC ne ferait pas ?

Oui, -fomit-frame-pointer (cf. #266). Si tu rajoutes ça et que tu utilises GCC 3.3, tu auras normalement du code comparable à celui de GTC. Mais vu les résultats du message #303, il y en a probablement d'autres.

Par optimisations qui font gagner beaucoup de place, que GCC (ou peut-être que c'est le linker, pas le compilateur) ne fait pas par défaut, il y a les conversions lea xxx.l,an, jsr xxx.l -> lea d(pc),an, jsr d(pc)/bsr. jsr xxx.l prend 6 octets + 4 octets pour la relocation, jsr d(pc) et bsr en prennent 4. Pourtant, ces conversions sont parfaitement licites, font gagner de la place et du temps, s'il y a moins de 32 KO de différence...

Le problème est ce "s'il y a moins de 32 KO de différence".
Et pour avoir ce que tu décris, il suffit de compiler avec -fno-function-cse -Wa,--pcrel. (Tiens, le fait de passer --pcrel à GNU as me fait gagner pas mal de place pour Backgammon.)
D'ailleurs, tu peux aussi dire à GNU as de mettre toutes les références en PC-relatif (pour les instructions qui le permettent), pas seulement les branchements. Pour cela, utilise le switch -l de GNU as, c'est-à-dire -Wa,-l.

Bon, le début de la page 10 m'a échappé, donc je vais y répondre maintenant:

Pollux
a écrit : Sans oublier les labels locaux de la forme \label, et qui sont définis jusque dans les accolades (assez pratique pour les sauts en arrière du type asm { \ret rts ; myfunc: add.w d0,d0 ; bne \ret ; ds.w 128 ; addq.w #1,d0 ; rts } )

GNU as (et donc l'assembleur inline de GCC) utilise des numéros pour ça: http://tigcc.ticalc.org/doc/gnuasm.html#SEC48L.

Pollux a écrit :
Je rappelle que Tiltmaze se compile sans la moindre modification...

Bon je suis pas totalement sûr que la version GTC n'a pas de bug mais en tout cas :
TI-GCC > 8280 octets GTC > 7870 octets

la version GTC fait en fait 7960 octets

Avec GCC 3.3 et en rajoutant -fomit-frame-pointer, ça fait 8056 octets. Mais la différence n'est pas si énorme que ça.

Pollux a écrit :
Et hop, TI-Mahjongg se recompile lui aussi avec GTC sans une seule modification!
En PPG (puisque c'est le format de la distribution TICT), GTC->6762 octets ; TIGCC->7112 octets.

Avec GCC 3.3 et en utilisant -Os -fomit-frame-pointer à la place de -O2, ça fait 6971 octets.

Pollux, la différence de taille serait-elle dûe au fait que tu as tout mis dans un seul fichier .c pour que GTC avale, et que cela permet des références PC-relatives là où la compilation séparée ne le permet pas (sauf si on utilise -Wa,-l, ce qui serait d'ailleurs possible ici vu que la taille totale de chacun de ces programmes fait moins de 32 KO)?
Ah non, les programmes en question font déjà ça.

En rajoutant -fno-function-cse, on gagne encore 8 octets sur la taille du PPG de TI-Mahjongg (normal, les appels répétitifs se compressent mieux). Mais on n'y est toujours pas.

> bon, les vacances de noel sont bientôt finies ?
Mais non

> c ce que je lui dit depuis hier, mais il veut pas me croire. Il continus à se battre ensemble
Mais euh c'est pas de ma faute euh, il fait rien que de m'embêter d'abord!


> GNU as (et donc l'assembleur inline de GCC) utilise des numéros pour ça
Oui c'est vrai, j'avais oublié de dire qu'on ne peut pas faire de labels locaux avec un nom humain dans GCC. Mais ma remarque était surtout adressée à A68k ou Nitro AS, dont la portée des labels locaux n'est pas très bien gérée...

> Mais la différence n'est pas si énorme que ça.
Tiens c'est bizarre, au début tu disais que le moindre % de différence était significatif et qu'il fallait refuser de compiler quoi que ce soit avec GTC pour cette raison

Si je dis que je ne trouve pas ça un vrai problème, ce n'est pas parce que je ne l'ai jamais rencontré dans mes projets personnels, mais parce que le fait de mettre le nom 2 fois ne me dérange pas du tout. Le copier-coller est fait pour ça. Comment penses-tu que j'ai fait pour mes sprites en 0b? Je n'ai pas utilisé de logiciel d'édition d'images, juste des lignes tapées à la main et du copier-coller.

Le copier coller ne suffit pas, puisque tu es obligé de renommer offsetof(SYM_ENTRY,handle) en SYM_ENTRY__handle

Pollux a écrit :
> GNU as (et donc l'assembleur inline de GCC) utilise des numéros pour ça Oui c'est vrai, j'avais oublié de dire qu'on ne peut pas faire de labels locaux avec un nom humain dans GCC.

Pour le genre d'exemple que tu as montré, un label 0: marche très bien.

> Mais la différence n'est pas si énorme que ça.
Tiens c'est bizarre, au début tu disais que le moindre % de différence était significatif et qu'il fallait refuser de compiler quoi que ce soit avec GTC pour cette raison

Sauf que TIGCC contient des options d'optimisation aggressive qui permettent de gagner ces derniers octets:

tigcc -Os -fomit-frame-pointer -Wa,-l -fno-function-cse -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -mregparm=6 -W -Wall tiltmaze.c
et hop, 7797 octets (contre 7960).

tigcc -Os -fno-defer-pop -fomit-frame-pointer -Wa,-l -fno-function-cse -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -mregparm=6 -pack mahjdata -o mahjongg timah.c
après remplacement de:
void (*df)(void*,void*,int);
et:
df = (void(*)(void*,void*,int))ScrRectFill;
et:
df = (void(*)(void*,void*,int))DrawClipRect;
par:
void (* ATTR_TIOS df)(void*,void*,int);
et:
df = (void(* ATTR_TIOS)(void*,void*,int))_rom_call_addr(189);
et:
df = (void(* ATTR_TIOS)(void*,void*,int))_rom_call_addr(195);
respectivement (dans DrawColorRect) et hop, un PPG de 6761 à 6763 octets selon l'essai, contre 6762 octets pour GTC dans ton essai. (Il a l'air d'y avoir plusieurs composantes aléatoires qui font osciller le résultat, mais on est à égalité. )

Pollux a écrit :
Le copier coller ne suffit pas, puisque tu es obligé de renommer offsetof(SYM_ENTRY,handle) en SYM_ENTRY__handle

Copier-coller, supprimer 1 caractère, rajouter 2 autres (voire un seul si on s'en contente). Total: 5 secondes.

Et j'ai mieux, grâce aux nouvelles options de GCC 3.3 (qui ne sont pas encore dans la documentation de TIGCC, c'est pour ça que je ne les ai pas essayées tout de suite):
tigcc -Os -fno-defer-pop -fno-if-conversion -fomit-frame-pointer -Wa,-l -fno-function-cse -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -mregparm=6 -pack mahjdata -o mahjongg timah.c
-> PPG de 6743 octets

-fno-if-conversion permet aussi de gagner 4 octets supplémentaires sur TI-TiltMaze. -fno-defer-pop n'est pas une bonne idée pour les programmes non compressés.

Donc, XDanger, voilà les optimisations à utiliser pour avoir du code optimal.

Je vais essayer -Wa,l.

>Donc, XDanger, voilà les optimisations à utiliser pour avoir du code optimal.
En taille, oui. Pour un jeu tel que TI-Mahjongg, on se moque un peu de la vitesse; mais le fait d'utiliser les ROM_CALLs par F-Line va ralentir le programme, forcément...

mais Kevin, GTC gère aussi les F-Line Je recompilerai avec les F-Line, même si les F-Line sont une véritable horreur et qu'il ne servent jamais...

Sinon c quoi -Wa,l ?

> Pour le genre d'exemple que tu as montré, un label 0: marche très bien.
ça n'était qu'un exemple, dans la pratique, les fonctions sont bien plus grosses que ça (n'importe quelle fonction ASM comporte une bonne vingtaine de labels locaux, alors pour s'y retrouver, c pas top )

Pollux a écrit :
mais Kevin, GTC gère aussi les F-Line

Depuis quand? La dernière fois qu'on en a parlé, ils n'y étaient pas...

Kevin Kofler a écrit (#32) :
Et est-ce que GTC sait faire ça?
tigcc -Os -fomit-frame-pointer -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse test3.c
Linked test3 - Size: 2041 bytes Je n'ai retiré aucun patch, et j'ai une taille du 89z de 2129 octets seulement.

Pollux a écrit (#33) :
Non parce que c lent, et donc si on veut faire un prog lent mais petit, on pourra bientôt utiliser GT-Basic

Sinon c quoi -Wa,l ?

Ça dit à GNU as de mettre les références externes en PC-relatif, à condition qu'une référence PC-relative soit permise à cet endroit. Normalement, GNU as n'utilise le PC-relatif que pour les références internes, pour lesquelles il peut vérifier que la distance fasse bien moins de 32 KO. Mais pour un programme de moins de 32 KO en total, l'utilisation de -Wa,l ne comporte aucun risque. Et pour un programme de plus de 32 KO, soit ça marchera quand-même, soit on aura droit à une erreur du linker.

> Pour le genre d'exemple que tu as montré, un label 0: marche très bien.
ça n'était qu'un exemple, dans la pratique, les fonctions sont bien plus grosses que ça (n'importe quelle fonction ASM comporte une bonne vingtaine de labels locaux, alors pour s'y retrouver, c pas top )

Mets un préfixe à tous tes labels. Ce n'est pas plus lourd que le '\'.

> > mais Kevin, GTC gère aussi les F-Line
> Depuis quand? La dernière fois qu'on en a parlé, ils n'y étaient pas...
Oui, mais ça m'a pris environ 5 minutes chrono à rajouter (et en plus les function-cse marchent pour tout ce qui est autre chose que des ROM_CALLs )


> Mets un préfixe à tous tes labels. Ce n'est pas plus lourd que le '\'.
Bien sûr que si, tu es obligé de rajouter un truc du style __DrawChar_ devant (ce qui rend déjà pas mal illisible), et pour peu que tu veuilles créer une nouvelle fonction DrawCharInv, tu es obligé de renommer tous tes labels...

Ca n'est pas la majorité des programmes qui fait plus de 32 KO, donc -Wa,l est parfait.
Pollux, je voulais savoir si GTC faisait cela en standard ?

Pollux a écrit :
> > mais Kevin, GTC gère aussi les F-Line
> Depuis quand? La dernière fois qu'on en a parlé, ils n'y étaient pas...
Oui, mais ça m'a pris environ 5 minutes chrono à rajouter (et en plus les function-cse marchent pour tout ce qui est autre chose que des ROM_CALLs )

Tiens, il va falloir que je m'amuse un peu avec GCC.

> Mets un préfixe à tous tes labels. Ce n'est pas plus lourd que le '\'. Bien sûr que si, tu es obligé de rajouter un truc du style __DrawChar_ devant (ce qui rend déjà pas mal illisible),

Mais non, c'est très lisible.

et pour peu que tu veuilles créer une nouvelle fonction DrawCharInv, tu es obligé de renommer tous tes labels...

Un remplacement automatique fait ça en 10 secondes.

Kevin Kofler
a écrit : Un remplacement automatique fait ça en 10 secondes.

Et ça peut être dangereux. Je t'ai déjà entendu le dire.

Kevin tu es vraiment de mauvaise foi

> Kevin Kofler a écrit :
> Un remplacement automatique fait ça en 10 secondes. Et ça peut être dangereux. Je t'ai déjà entendu le dire.

Oui, d'autant plus que tu ne peux pas faire 'remplacer tout'...

Kevin, est-ce que le nouveau linker de TIGCC va optimiser les jsr xxx.l en bsr/jsr d(pc) et les lea xxx.l,an en lea d(pc),an quand c'est possible ?
Actuellement (TIGCC 0.94 Beta 20, GCC 3.2), ça ne le fait malheureusement pas...

> Oui, d'autant plus que tu ne peux pas faire 'remplacer tout'...
Précise quel OS, quelle version de TIGCC, ...
Pour moi (Win ME, TIGCC 0.94 Beta 20), le 'remplacer tout' semble marcher...

Bien sûr que la fonction 'remplacer tout' marche, je disais que la fonction 'remplacer tout' ne permettait pas de renommer seulement la moitié des labels, et donc qu'on est obligé de faire 'remplacer' une bonne vingtaine de fois

Bah, désolé... Je suis bête (je précise que ça n'est pas parce que j'ai fait la fête cette nuit)...

Kevin > LOL. À ce rythme, GTC sera peut-être utilisable en 2010 avec un peu de chance.
Pollux >> Je vois encore une fois que tu ne rates pas une occasion de descendre la "concurrence"...
Dommage que ma bonne humeur me retienne de dire à Kevin qu'il est con



Kevin Kofler, à propos des F-line > Backgammon les utilise en tout cas.
Oué, le Fline n'est utilisé que par quelques programmes lents. Si GTC ne les supportait pas, ce ne serait pas grave, ils ne sont pas indispensables. Mais il les supporte.


> tu peux aussi dire à GNU as de mettre toutes les références en PC-relatif
Tu ne pourrais pas patcher GNUas pour qu'il le fasse par défaut, et seulement pour les références internes à une source ?

Thibaut> dans KII, j'utilise les appels aux RC par 1111 (F-line, comme c appelé dans TIGCC... j'ai gardé l'habitude de les appeler 1111, vu que c le message d'erreur qui s'affiche sur les ROM inférieures à (je crois) 2.04, même si 0xf = 0b1111 )

mais force est de reconnaitre que je n'appelle pas de RC dans le jeu en lui-même : ceux que j'appelle, c dans les initialisations/dé-initialisations, et dans les menus )

Tu as bien fait de ne pas les employer dans la partie rapide de ton jeu

oué, clair
mais bon, vu que pas mal de RC rament pas mal... ça doit pas changer gd-gd chose au niveau vitesse
(enfin, ça dépend pr lesquels)

si tu affiche tes sprites avec des BitmapPut, ma foi, que tu appelle le RC avec le 1111 ou de façon normale, tu dois pas sentir la différence

vu que j'utilse pas de RC dans le moteur en lui-même, ma fois, j'ai choisi ce qui prend le moins de mémoire :
même en installant le Handler pr faire tourner le 1111 sur les ROM qui en ont pas, ça prend moins de mem comme ça
(j'économise la mem dans les menus... et je la reprend dans le moteur, en gros )

Il y a des ROM_CALLs très bien programmés. Ceux qui traitent les chaînes de caractères entre autres.

bah ils ont oublié de bien programmer la routine d'affichage de chaine de caractère:]

tiens je crois connaitre l'origine de ce post

erf...

Thibaut
a écrit : Il y a des ROM_CALLs très bien programmés. Ceux qui traitent les chaînes de caractères entre autres.

Normal, c'est Motorola qui les a programmés. C'est pas TI.