Où est CC ? - Page 6

J'ai édité mon message #146 pour mettre quelque chose d'utile (lis-le s'il te plaît). C'était un post croisé qui est devenu totalement inutile de par ton message #143.

XDanger
a écrit : Alors à ce moment-là, pour faire un bench correct, on doit mettre -Wa,-l et -fomit-frame-pointer à GCC...

On ne peut pas. TI-Chess est trop gros. Mais on pourra utiliser le switch --optimize-code de ld-tigcc. Ça gaspillera toujours 2 octets par adresse parce qu'on ne peut pas supprimer 2 octets au plein milieu d'une section d'un fichier objet (on doit donc mettre un nop dans la place libérée par le changement en du PC-relatif), mais ça économisera les entrées dans la table de relogements. J'ai testé et on économise 336 octets sur TI-Chess même après avoir compilé tout en une seule fois (donc tu as tord dans ton message #149, Pollux!).

Bien sûr...
Ce que je voulais dire, c'est que pour d'autres projets, notamment ceux de moins de 32 KO, il ne faudra pas oublier de mettre -Wa,-l et -fomit-frame-pointer pour GCC...

Ah oui je précise que j'ai désactivé la touche de debug (#undef ENABLE_TESTKEY)
Et puis si tu veux tout recompiler en un fichier, tu vas avoir des problèmes de ROM_CALLs, parce que les définitions gore de TI-Chess :
#define A1 ...
#define F3 ...
interfèrent avec la macro _rom_call, donc j'ai changé F3 en C_F3.

Je publie la source ou le diff dès que j'aurai fait un peu de ménage.

> (donc tu as tord dans ton message #150, Pollux!).
Absolument pas, j'ai regroupé tous les fichiers en une source, et donc il n'y a qu'un seul fichier objet. Toute optimisation du style -Wa,-l ne change strictement rien (même pas de un octet ).

Pollux a écrit :
Ah oui je précise que j'ai désactivé la touche de debug (#undef ENABLE_TESTKEY)
Et puis si tu veux tout recompiler en un fichier, tu vas avoir des problèmes de ROM_CALLs, parce que les définitions gore de TI-Chess :
#define A1 ...
#define F3 ... interfèrent avec la macro _rom_call, donc j'ai changé F3 en C_F3.

Je n'ai pas eu de problèmes avec ça... L'exécutable que j'ai compilé tourne.

> (donc tu as tord dans ton message #150, Pollux!). Absolument pas, j'ai regroupé tous les fichiers en une source, et donc il n'y a qu'un seul fichier objet.

Dans mon test aussi (cf. édition du message #146!), et pourtant, ld-tigcc trouve 62 références absolues qu'il peut changer en références PC-relatives. Probablement à cause des références vers tigcc.a (ou peut-être parce que GNU as n'a pas bien fait son travail).

Toute optimisation du style -Wa,-l ne change strictement rien (même pas de un octet ).

Chez moi, ça change de 336 octets (en utilisant ld-tigcc --optimize-code)!

Pollux
a écrit : Ah oui je précise que j'ai désactivé la touche de debug (#undef ENABLE_TESTKEY)

OK, on s'y rapproche, mais tu as choisi quel modèle et quelle langue? Et quelle version de GCC 3.3? Parce qu'avant d'avoir touché à ENABLE_TESTKEY, j'avais un exécutable plus grand que toi, mais là j'en ai un plus petit que toi.

Pollux n'a malheureusement pas répondu à:
"Donne exactement les options de compilation que tu utilises pour chacun des deux compilateurs, aussi."...

Voilà l'exécutable le plus gros que j'ai pu obtenir avec la touche de debug désactivée:

tigcc -Os -fomit-frame-pointer -DUSE_TI92P -DUSE_V200 -DLANG_FRENCH hack.c
Linked hack - Size: 50313 bytes

(89z de 50401 octets, alors que toi, Pollux, tu prétends être à 50945 octets avec GCC).
Et d'ailleurs, ld-tigcc --optimize-code me donne un exécutable de 50077 octets dans ce cas. 59 entrées de table de relogement économisées.

Quant au plus petit (TI-89, anglais, optimisation du linker), c'est un 89z de 49541 octets.

Ah oui désolé j'avais oublié les références à tigcc.a qui sont externes.

J'ai compilé pour 89, la ligne de commande exacte est :
tigcc -DUSE_TI89 -DLANG_french -Os -fomit-frame-pointer -Wall -W -Wwrite-strings tic.c
Je précise que j'ai pris la taille du 89z, mais la différence vient peut-être d'une modification de test que j'ai faite (ou alors une différence de version, j'ai TIGCC0.94b18, LIB2.5, GCC 3.3 pre13). Enfin bon il faut que je fasse le ménage dans le répertoire tichess

Moi, j'ai la 0.94 SP4, pour les tests sans optimisation du linker la version de TIGCCLIB qui va avec, pour les tests avec optimisation du linker celle livrée avec ld-tigcc, et comme toi j'ai GCC 3.3-tigcc-pre13.

Mais on pourra utiliser le switch --optimize-code de ld-tigcc. Ça gaspillera toujours 2 octets par adresse parce qu'on ne peut pas supprimer 2 octets au plein milieu d'une section d'un fichier objet (on doit donc mettre un nop dans la place libérée par le changement en du PC-relatif), mais ça économisera les entrées dans la table de relogements.

C'est vraiment dommage qu'on ne puisse pas supprimer 2 octets en plein milieu d'une section d'un fichier objet...

On ne peut pas le faire parce que ça invaliderait toutes les références PC-relatives.

Bien sûr, mais c'est dommage de mettre un nop pour presque rien...
Cela dit, il faut voir le bon côté des choses: --optimize-code sauve quand même 4 * le nombre de relocations supprimées par le passage xxx.l -> pc-relatif...

> Je n'ai pas eu de problèmes avec ça... L'exécutable que j'ai compilé tourne.
Hmm c bizarre... Et je n'arrive pas à voir l'output du préprocesseur avec -E.

C'est corrigé dans la version la plus récente de TIGCC. Tu as une vieille bêta.

oué

En fait je viens de me rendre compte que lors de la concaténation avec ##, l'expansion des macros se fait après la concaténation (et pas avant comme je le faisais dans GTC).

Euh sinon juste une question: après
#define x3 grr
10x3 est censé se transformer en 10grr ou pas?

XDanger
a écrit : C'est vraiment dommage qu'on ne puisse pas supprimer 2 octets en plein milieu d'une section d'un fichier objet...

Le compilateur Sierra, lui, ça ne le gene pas. Il est capable de faire plusieurs passes compilation/linker pour optimiser tout ça... comme quoi GCC c'est bien gentil mais c'est loin d'être optimal encore.

Pollux
a écrit : En fait je viens de me rendre compte que lors de la concaténation avec ##, l'expansion des macros se fait après la concaténation (et pas avant comme je le faisais dans GTC).

Ben oui, c'est non-seulement écrit dans le standard C, mais aussi dans la documentation du préprocesseur de GCC. Tu n'as même pas fait le minimum d'effort pour t'informer sur le langage que tu prétends être l'entrée acceptée par ton compilateur avant de commencer à l'implémenter!

Euh sinon juste une question: après
#define x3 grr 10x3 est censé se transformer en 10grr ou pas?

NON! C'est au plein milieu d'un token, donc on n'y touche pas (et j'ai testé avec gcc -E pour être sûr de ne pas raconter une bêtise).

Ça va Kevin, sois un peu plus souple avec lui. Les spécificités du C sont nombreuses, c'est normal qu'il se perde un peu.
Bon, sinon, je trouve que pour un compilo "techniquement inférieur", il se débrouille plutôt bien question taille. Reste à voir si la vitesse suit

Ben oui, c'est non-seulement écrit dans le standard C, mais aussi dans la documentation du préprocesseur de GCC. Tu n'as même pas fait le minimum d'effort pour t'informer sur le langage que tu prétends être l'entrée acceptée par ton compilateur avant de commencer à l'implémenter!

Excuse moi, mais j'ai lu et relu la doc de TI-GCC sur le préprocesseur, et ce n'est pas clairement précisé dedans. En tout cas c'est corrigé.

NON! C'est au plein milieu d'un token, donc on n'y touche pas (et j'ai testé avec gcc -E pour être sûr de ne pas raconter une bêtise).

OK, c'est ce que fait GTC, mais je voulais être sûr.

Reste à voir si la vitesse suit

Je n'attends que vos suggestions de bench.

Juste un truc tout con: ti-chess a un chronomètre de temps de jeu. Si tu fait 2 parties identiques tu verras bien la différence de temps entre les 2 ordinateur(a mois qu'il y ait une partie d'aléatoire?)

Pollux
a écrit : Excuse moi, mais j'ai lu et relu la doc de TI-GCC sur le préprocesseur, et ce n'est pas clairement précisé dedans.

Si:

http://tigcc.ticalc.org/doc/cpp.html#SEC17 (Stringification)

When a macro parameter is used with a leading #, the preprocessor replaces it with the literal text of the actual argument, converted to a string constant. Unlike normal parameter replacement, the argument is not macro-expanded first. [...] If you want to stringify the result of expansion of a macro argument, you have to use two levels of macros.

http://tigcc.ticalc.org/doc/cpp.html#SEC18 (Concatenation)

As with stringification, the actual argument is not macro-expanded first.

Uther Lightbringer
a écrit : Juste un truc tout con: ti-chess a un chronomètre de temps de jeu. Si tu fait 2 parties identiques tu verras bien la différence de temps entre les 2 ordinateur(a mois qu'il y ait une partie d'aléatoire?)

Il y a un peu d'aléatoire.

Il y a un peu d'aléatoire.

sa doit pas être bien dificile de recompiler en remplacant la fonction aléatoire par un nombre fixe.

> Le compilateur Sierra, lui, ça ne le gene pas. Il est capable de faire plusieurs passes compilation/linker pour optimiser tout ça... comme quoi GCC c'est bien gentil mais c'est loin d'être optimal encore.
En effet, ça n'est pas optimal. N'oublie pas cependant que GCC n'est pas, à la base, fait pour des M68k; et n'oublie pas non plus que GTC < GCC (pas forcément sur ce point-là, mais sur d'autres)...

> http://tigcc.ticalc.org/doc/cpp.html#SEC18 (Concatenation)
Ah ben désolé mais la version de TI-GCC Lib que j'ai ne le précisait pas. En revanche pour la stringification c'était précisé.

C'est faux. Depuis que la documentation du préprocesseur est intégrée à notre documentation (29 septembre 2000), il y a écrit sous "Argument prescan": "The prescan is not done when an argument is stringified or concatenated." (phrase qui se retrouve maintenant sous la forme: "If an argument is stringified or concatenated, the prescan does not occur.", accompagnée de plus de détails).

Avec un peu de patience, et les libs de Kevin et Jarode, on devrait quand meme pouvoir faire de bonnes choses rien qu'aévec AS(). C'est LE compilo qui fonctionne bien on-calc.

ce n'est pas le seul tout simplement ?

Non AS(d'ailleur c'est un assembleur pas un compilo) n'est pas le seul, il y a aussi AS92(mais qui a pas mal de retard en fait)

AS92 n'est pas la mm chose je croyais