Thibaut (./84) :
us les headers de TIGCC pour GTC ? Actuellement, il faut modifier chaque fichier source (.c et .h) pour remplacer les #include <kbd.h | limits.h | peekpoke.h | graph.h, etc>Pollux, penses-tu que c'est une bonne idée de porter toib.h> par #include <tigcclort de sources si tous ces headers étaient définis. Chacun ne contiendrait qu'une seule ligne :#include <tigcclib.h>Ca simplifierait le pCa prendrait même pas 1 ko de plus sur la calto.

Euh, tu dois avoir une vieille version de GTC, tu as essayé avec celle que je t'ai envoyée ?

geogeo (./85) :
Y a un truc qui me chiffonne moi. Comment une simple compilateur sur calculatrice (peu de mémoire, un processeur plus lent) peut-il appliquer une quantité importante d'optimisations qui demandent plusieurs années de développement pour une équipe entière telle que GCC ?
Pour affirmer que GTC est plus rapide que TIGCC il faudrait non pas tester la compilation de deux projets mais plusieurs dizaines de tailles diverses (factoriel, jeu d'échecs, code source de GTC lui même...).
Si oui GTC est plus rapide que TIGCC alors là franchement il faut revoir d'urgence la politique d'optimisations de TIGCC.

Pour la vitesse d'exécution c'est pas sûr du tout que GTC soit plus rapide que TIGCC ; apparemment c'est le cas dans le test de Thibaut, mais à mon avis ce sera l'inverse dans d'autres tests... La vitesse d'exécution c'est qqch de très aléatoire, qui dépend énormément du style de codage (petites ou grosses fonctions, variables temporaires ou globales, switches, etc), donc c'est impossible de dire qu'un compilateur est plus rapide qu'un autre en général. Pour la taille, c'est déjà qqch qui varie nettement moins d'un projet à l'autre -- ne serait-ce que parce que la vitesse dépend d'une toute petite fraction du code et donc des optimisations, alors que la taille correspond à la somme de tout le code.