Tiens en fait je viens de me rendre compte que c'était le PPG d'une vieille version de GTC... La dernière fait 6423 octets
(au lieu de 6514)
XDanger :
> pleins de patchs ajoutés d'office au code que seuls les connaisseurs peuvent désactiver
Faux, il suffit de savoir lire la doc...
Cela dit, Thibaut n'a pas tort vu la façon dont la taille du stub inclus par défaut a augmenté avec le temps...
OK, mais pourquoi donnes-tu la taille du PPG et pas la taille du code non compressé (c'est bien ce que tu as écrit) ?
Parce que TI-Mahjongg était distribué au format PPG, tout simplement. Je crois que dans ce cas précis GTC reste toujours plus efficace en non compressé (mais la différence est moins flagrante qu'en PPG).
Si j'ai compris un tant soit peu quelque chose au principe de la compression, c'est justement de compresser les séquences redondantes... Alors, je ne vois que deux possibilités:
* ou bien GTC génère du code très nettement plus petit que celui que génère GCC (TIGCC), probablement de plus de 10%, qui même moins compressible, sera plus petit une fois compressé (et ça, je ne peux pas le vérifier);
* ou bien il y a plus de redondance dans ton code...
lol
En fait ça dépend beaucoup des progs, GTC n'est pas "plus redondant" ou "moins redondant" que TIGCC, c'est variable. D'ailleurs à mon avis la capacité d'un compilo à choisir entre deux séquences de code équivalentes (en taille et en vitesse), l'une plus redondante, l'autre moins, est une qualité pour le compilo... Perso quand je programme en ASM pour un prog qui doit être compressé, je fais attention, s'il y a des formes équivalentes, à choisir les plus redondantes...
> Je ne parle même pas du support des kernels nouvelle génération (euh du kernel nouvelle génération plutôt), que vous refusez obstinément.
D'une, je ne suis pas membre de la TIGCC Team (malgré ce que certains ânes rabâchent, allez savoir pourquoi, peut-être PARFOIS, pas toujours, pour cacher leur manque d'arguments). Ca n'est donc pas à moi de décider ça. De deux, on a déjà expliqué POURQUOI on ne voulait pas de PreOS...
Ca ne s'adressait pas à toi en particulier
Ensuite, si j'ai bien compris la seule raison de ne pas vouloir de PreOS est qu'il est backwards-compatible avec les anciens kernels et que de donc vous ne voulez pas ajouter les fonctions de PreOS non inclues dans les anciens kernels? C'est complètement bidon comme argument
Si un programmeur veut faire un prog pour PreOS (et uniquement PreOS), il devrait en avoir le droit! D'ailleurs rien que le fait d'avoir une gestion de la version des libs devrait être une motivation suffisante pour que qqun qui programme en mode kernel se mette à programmer uniquement pour PreOS.
> mais il ne faut pas oublier que GCC subit des beta-tests gigantesques (comparez le nombre d'utilisateurs de GCC au nombre de possesseurs d'une TI-68k), chose qu'on ne peut pas se permettre de faire dans le monde restreint de la communauté TI
Certes, mais on peut faire un bêta-test public, au moins à partir d'un certain point, plutôt qu'un bêta-test privé. Ca sera beaucoup moins restreint...
Et alors? Ca ne change rien au fait qu'il y a bcp moins d'utilisateurs de TIGCC que de GCC, et si GCC ne devait compter que sur les beta-tests de TIGCC, il serait encore extrêmement buggé...
nitro>
En même temps c'est plutôt compréhensible que les dév de GCC soient suffisamment méfiants pour ne pas accepter directement des contributions de n'importe qui, sinon ce serait un peu la fête du slip...
J'ai fais exprès. Je savais que tu réagirais, et toi seul, connaissant ta tendance bourgeoise 
(au lieu de 6514)
Si un programmeur veut faire un prog pour PreOS (et uniquement PreOS), il devrait en avoir le droit! D'ailleurs rien que le fait d'avoir une gestion de la version des libs devrait être une motivation suffisante pour que qqun qui programme en mode kernel se mette à programmer uniquement pour PreOS.
)
