Niveaux de gris - Page 5

Dans mes souvenirs les résustats n'étaient pas mal du tout (mieux que ceux de tigccc ?)

ouais moi je trouve que c'est les plus beaux.

les jeux de FlashZ sont vraiment magnifiques ses jeux

ba c FlashZ quoi :]

Ça sert à quoi le dérelogement ?

Avec une table de relogements redondante comme celle de AMS, à rien (et AMS n'effectue pas de dérelogement). Avec une table de relogements non-redondante, l'offset de destination n'est pas stocké dans la table, mais à l'endroit dans lequel on place l'adresse finale, donc pour ravoir l'offset à la fin pour pouvoir effectuer un nouveau relogement plus tard, il faut déreloger le programme.

Encore un truc qui va augmenter la taille de base des progs créés par TIGCC hein?

non, justement c'est pour la diminuer (c'est ce qu'a expliqué KK)
mais le gain/perte dependra de la taille du prog
(en toute logique)

Surtout du nombre de relogement . Un prog avec énormément de variables globales gagnera beaucoup mais pour un prog classique la différence sera faible. Sur CC par exemple, le gain devrait être très sensible.

XDanger :
> Pas mieux qu'avant, à mon avis. Ces switches sont et ont toujours été expérimentaux. Je sais, mais c'est un peu dommage... Il est bien sûr possible de faire sans, mais ils pourraient être intéressants (mode pc-relatif = pas de table de relogements; une solution pour s'en passer est soit -freg-relative-an qui ne marche pas super bien, soit une global register variable).

Sur un prog C de 8Ko environ je viens de tester ce switch, avec a6-> illegal instruction, a5-> memory error mais par contre avec a4 je gagne plus d'un Ko! Je e connaissais pas ce switch, mais je m'en souviendrai

Je suppose que tu as -fomit-frame-pointer dans les options de compilation et que OPTIMIZE_ROM_CALLS n'est pas défini ? -fomit-frame-pointer qui n'enlève le frame pointer que si c'est possible (le plantage vient probablement de là)...

-fomit-frame-pointer oui, OPTIMIZE_ROM_CALL je l'ai défini aussi. Je me doutait bien que les plantages venait de là, mais si ça marche avec au moins l'un des an c'est déjà pas mal

Brunni
: Encore un truc qui va augmenter la taille de base des progs créés par TIGCC hein?

Pas la taille de base. Ça ne sera pas utilisé si tu ne définis pas une option (c'est une option de TIGCCLIB, donc règlable avec un #define ou un -D passé à GCC) explicitement.

La seule option parmis toutes ces nouveautés qui est activée par défaut est le support des BSS, mais il suffit de compiler avec -mno-bss (rajouté dans GCC 3.3.1-tigcc-pre17) pour que les BSS ne soient pas utilisés. Le linker est suffisamment intelligent pour ne pas inclure du code de gestion des BSS si la section BSS est vide.

Uther
: Surtout du nombre de relogement . Un prog avec énormément de variables globales gagnera beaucoup mais pour un prog classique la différence sera faible. Sur CC par exemple, le gain devrait être très sensible.

On a gagné presque 10 KO sur CC (taille non compressée) avec le nouveau linker. Support des BSS, optimisation anti-relogements, tables de relogement compressées, tout ça se fait sentir.

10 KO sur CC

Ouah c'et vraiment pas mal.

Alors je me réjouis... (c'est quoi les BSS, à quoi ça sert?)

C'est un espace de variable local.

Brunni
: Alors je me réjouis... (c'est quoi les BSS, à quoi ça sert?)

Variables globales initialisées à 0 (ou pas initialisées du tout, c'est règlable avec une option), automatiquement allouées au lancement du programme. Ça évite de prendre de la place dans le programme pour les variables globales qui n'ont pas besoin d'être initialisées.

Ximoon, est-ce que tu as le switch -Wa,-l (switch -l de GNU as) ? Ca améliore les sources en plusieurs fichiers...
Et ne laisser que deux registres d'adresse non destructibles (a2 et a3) peut être préjudiciable à ton programme (typiquement, ça le serait pour une des fonctions de tthdex qui a un grand nombre de pointeurs)... S'il n'utilise que peu de ROM_CALLs, tu devrais plutôt ne pas définir OPTIMIZE_ROM_CALLS et mettre -freg-relative-a5.

-Os -Wall -W -mregparm -fomit-frame-pointer -foptimize-sibling-calls -fregmove -freg-relative-a4
OPTIMIZE_ROM_CALLS, NO_AMS_CHECK, SAVE_SCREEN, NO_EXIT_SUPPORT

C'est le premier prog que je fais en C, j'ai mis les switchs qui me semblaient intéressants dans la doc, à tort peut-être.

Et c'est plus gros avec la méthoe que tu proposes

Pas la peine de passer -foptimize-sibling-calls -fregmove, ces options sont déjà activées par -Os (ou -O2).

Kevin Kofler
: Le code de relogement pour relogements compressés prend actuellement 160 octets, 96 desquels sont pour le décodage des offsets, et donc partagés avec le support des BSS et d'autres fonctionnalités liées aux relogements. Et il me semble qu'il y a encore des optimisations possibles, donc d'ici la version finale, ça peut encore être réduit de quelques octets.

Et voilà: 156 octets (4 de moins), dont 98 (2 de plus) partageables avec BSS etc.
Et j'ai pris une adresse de référence plus adaptée (pas la peine d'avoir une adresse de référence avant la fin du code de relogement, on ne peut rien reloger là-bas), ce qui réduit le premier offset, donc peut permettre de mieux compresser le début de la table (avec le codage employé, plus l'offset est petit, moins il prendra de place compressé).

Au fait j'y pense... ça ne sera plus du _nostub du coup... ?

tthdex utilise
-O2 -fomit-frame-pointer -Wall -W -Wwrite-strings -fexpensive-optimizations -Wpointer-arith -fno-function-cse -frerun-loop-opt -fgcse-lm -fgcse-sm -frerun-cse-after-loop -fgcse
+ -l pour GNU as.
(-fno-function-cse à cause des ROM_CALLs en F-Line).

Dans quels cas -frerun-loop-opt -fgcse-lm -fgcse-sm -frerun-cse-after-loop -fgcse améliorent-ils franchement le code ?

Ximoon
: Au fait j'y pense... ça ne sera plus du _nostub du coup... ?

Ça sera du nativement exécutable (sans kernel). Le programme se reloge lui-même.
Si on l'appelle _nostub ou non se discute. C'est juste une question de terminologie.

XDanger :
tthdex utilise
-O2 -fomit-frame-pointer -Wall -W -Wwrite-strings -fexpensive-optimizations -Wpointer-arith -fno-function-cse -frerun-loop-opt -fgcse-lm -fgcse-sm -frerun-cse-after-loop -fgcse
+ -l pour GNU as.
(-fno-function-cse à cause des ROM_CALLs en F-Line).
Dans quels cas -frerun-loop-opt -fgcse-lm -fgcse-sm -frerun-cse-after-loop -fgcse améliorent-ils franchement le code ?

Aucun. Ces flags sont déjà activés par -O2.
La même chose est valable pour -fexpensive-optimizations.

Il ne faut pas -O3 pour avoir -fexpensive-optimizations ?

Je croyais que justement les options activées par -O3 et pas par -O2 étaient toutes celles qui augmentent beaucoup le temps de compilation et n'améliorent pas tant que ça la qualité du code ? ce n'est pas justement ce que veut dire « expensive » ?
c'est bizarre...

Sally Brown :
Il ne faut pas -O3 pour avoir -fexpensive-optimizations ?

Non. J'ai vérifié dans le code source.

Je croyais que justement les options activées par -O3 et pas par -O2 étaient toutes celles qui augmentent beaucoup le temps de compilation et n'améliorent pas tant que ça la qualité du code ? ce n'est pas justement ce que veut dire « expensive » ? c'est bizarre...

Non, la différence entre -O2 et -O3 est que les optimisations qui augmentent de beaucoup la taille du code (inlining), et aussi le "register renaming" (qui ne sert à rien sur 68k, déjà parce qu'il n'y a pas de "scheduler" d'instructions 68k dans GCC et aussi parce qu'il n'y a pratiquement pas de pipeline, donc un "scheduler" dans le compilateur ne servirait à rien).

l'option -malign-int (je crois que c ça), elle permet de gagner en vitesse ?

perso, avec -f-reg-relative-a5 ou a4, ça plante, il me semble

squale92
: l'option -malign-int (je crois que c ça), elle permet de gagner en vitesse ?

Non.

argh.
elle fait perdre en vitesse ?

(parce qu'elle m'a fait gagner dans les 200 octets en espace mémoire)

squale92 :
argh. elle fait perdre en vitesse ?

Non.

(parce qu'elle m'a fait gagner dans les 200 octets en espace mémoire)

Elle t'a fait gagner de la mémoire???
Elle est censée augmenter la taille des programmes!
Je te signale aussi qu'il peut y avoir des problèmes avec les structures AMS si tu définis ce genre d'options non-standard.