Le compilateur GTC est-il mauvais ? - Page 2

La version minimale de l'OS est la 2.03.

Je parle pour TI-Chess là, où la version minimum est 1.00 dans la dernière version et je suppose que ça suffirait aussi dans la vieille version que tu testes, donc essaie de rajouter -DMIN_AMS=100.

Quant à Einstein, tu la mets pour quoi, cette version minimale? PpHd a dit à un moment que ce n'est pas nécessaire... En tout cas, même sans chercher plus loin, tu as là ton explication pour ta différence de taille, TIGCC vérifie correctement que l'AMS minimum est satisfait, GTC prie au surnaturel.

Kevin, l'AMS 1.00 ne doit plus tourner sur beaucoup de machines à ce jour... A part trafiquer le code source pour faire dire ce qu'on veut aux résultats, il n'y a n'a pas de grande utilité à essayer.
Le programme a été conçu comme il l'a été. Si on commence à trafiquer les sources pour faire dire ce qu'on veut aux résultats, ce n'est plus très honnête je trouve

Pour ton deuxième paragraphe : C'est de la mauvaise foi, non ? Le code de vérification fait 500 octets ??

Thibaut (./33) :
Kevin, l'AMS 1.00 ne doit plus tourner sur beaucoup de machines à ce jour... A part trafiquer le code source pour faire dire ce qu'on veut aux résultats, ça n'a pas grande utilité d'essayer.

Si, ça a l'intérêt que la comparaison sera honnête.
AMS 1.00 n'est pratiquement pas utilisé, mais le code mis pour tester si l'AMS est vraiment >=1.01, il est très réel et pratique, lui!

Le programme a été conçu comme il l'a été.

Mais tu testes une version obsolète, si ça te dérange, refais tes tests avec la 4.17 où ce problème a justement été corrigé.

Si on commence à trafiquer les sources pour faire dire ce qu'on veut aux résultats, ce n'est plus très honnête je trouve

Ce qui n'est pas honnête, c'est que GTC omet une validation nécessaire pour que des programmes ne plantent pas. (Pour TI-Chess, ça marche parce que le MIN_AMS devrait être 100 de toute façon, mais pour d'autres logiciels ça bogue.) Tu peux aussi utiliser -DNO_AMS_CHECK sinon, c'est l'option (fortement déconseillée) pour faire comme GTC, ça reviendra au même ici. Mais -DMIN_AMS=100 est plus propre.

Le code de vérification fait 500 octets ?

Ah oui, et pour tes tailles, tu comptes bien ttunpack_small, pas ttunpack_fast? C'est malhonnête aussi sinon (parce que le lanceur par défaut est "small", pour une raison).
Et tu comptes bien les tailles on-calc, pas celles sur PC? Parce que sinon tu ajoutes 2 fois le header PC pour TIGCC et 1 fois pour GTC (parce que TIGCC utilise un lanceur séparé), et puis c'est incorrect de toute façon. (Je te demande ça parce que la dernière fois où tu as fait ce genre de tests, tu avais utilisé des tailles sur PC. )

Edited_3651

J'y pensais aussi, mais j'osais pas le dire
En fait, à partir du moment où l'IDE active ces options automatiquement, c'est pas très gênant pour l'utilisateur.

Mais le fond de ta pensé est vrai : c'est remarquable que GTC s'en sorte mieux que TIGCC sans pour autant réaliser la quantité d'optimisations que font GCC et le linker

Kevin : Oui, ce sont bien les tailles sur la machine que je regarde. Oui, c'est bien ttunpack_small qui est généré.

Thibaut (./35) :
Le code de vérification fait 500 octets ?

Non, une cinquantaine (le message prend le plus de place). Il y a peut-être un autre truc aussi?

Et sinon, tu n'utilises pas les fonctionnalités du linker qui pourraient te faire gagner de la place, MLINK_FORMAT_RELOCS par exemple (et MLINK_FORMAT_BSS aussi).

Cela dit, il faut dire que la partie compilateur de GTC se bat plutôt bien en termes d'optimisation taille (et pourtant les GCC actuels ont amélioré l'optimisation), c'est surtout au niveau du linking où TIGCC est clairement meilleur.

EDIT: Je me disais bien que les GCC actuels ont amélioré l'optimisation, donc ça m'étonnait de voir ces chiffres, et effectivement, Thibaut a comparé avec un vieux GCC de 2004. Donc je retire l'affirmation que GTC se bat plutôt bien, vu que la comparaison ne veut rien dire.

Orion_ (./37) :
moi ce qui me choque c'est surtout qu'on soit obliger de parler pendant 2 pages d'option compliqué à passer à tigcc pour avoir un executable plus petit que gtc, alors que gtc n'a besoin d'aucune option...

GTC n'a pas besoin d'être compatible à 100% (ou 99% si vous voulez, mais je fais tout pour la compatibilité antérieure niveau source) avec des sources de 1999.

---

Le but du ./40 est surtout de justifier les réglages par défaut de TIGCC (surtout en ligne de commande, je déconseille d'utiliser la ligne de commande pour ça, mais on en a déjà parlé dans d'autres topics). Ne pas avoir à être compatible peut être un atout, mais c'est aussi un inconvénient. TIGCC compile toujours les sources écrites pour des versions de 1999 ou 2000, dans la plupart des cas sans aucune modification (pas avec toutes les optimisations actuelles, donc il vaut le coup de moderniser les sources si possible, mais ça compile).

Sinon, je dois quand-même dire que certains moyens de gagner de la place dans GTC sont une mauvaise idée, comme par exemple le fait que MIN_AMS n'est pas géré du tout, donc si on utilise un ROM_CALL d'un AMS autre que 1.00, ça va planter si on lance le programme avec un MIN_AMS moins récent.

Mais le compilateur est meilleur que certains autres prétendants (CC, ETP, ...), c'est clair.

Mais comme GTC tourne lui-même sur la calculatrice il doit être en mesure de détecter pour quelle version d'AMS il doit compiler, non ?

Réponse courte: Non.

Réponse longue: Déjà, il y a une version sur PC. Ensuite, la calculatrice utilisée pour compiler n'est pas forcément la seule sur laquelle le programme doit tourner. Et enfin, même s'il était en mesure de détecter ça, ça ne changerait pas qu'il ne le fait pas. La gestion de MIN_AMS de TIGCCLIB a été presque entièrement supprimée dans GTC. (Je suppose que les quelques endroits où il reste du MIN_AMS sont des oublis.)

Kevin Kofler (./42) :
Sinon, je dois quand-même dire que certains moyens de gagner de la place dans GTC sont une mauvaise idée, comme par exemple le fait que MIN_AMS n'est pas géré du tout, donc si on utilise un ROM_CALL d'un AMS autre que 1.00, ça va planter si on lance le programme avec un MIN_AMS moins récent.

Le binaire de TI Chess généré par GTC fait 2,5 ko de moins que celui généré par TIGCC avec les options par défaut de l'IDE.
Il y a tant de mauvais moyens que ça ?

Orion_ (./37) :
moi ce qui me choque c'est surtout qu'on soit obliger de parler pendant 2 pages d'option compliqué à passer à tigcc pour avoir un executable plus petit que gtc, alors que gtc n'a besoin d'aucune option...

Clairement... surtout quand on lit dans le topic d'à côté que les options sont faites pour ne surtout pas être changées...

Kevin
: Mais le compilateur est meilleur que certains autres prétendants (CC, ETP, ...), c'est clair.

Après ces 2 tests, je dirais même plus.


• GTC a réussit à compiler 1 projet moyen (Einstein) et un gros projet (TI Chess) sans véritables modifications en dehors du code assembleur (et le fichier de build évidemment).

Les modifications du code ASM ne sont pas faites par manque de fonctionnalités, mais parceque la syntaxe est différente, tout simplement.
Le code C se compile parfaitement, à deux détails près :
- 1 bug sur les variables de type JMP_BUF que Pollux devrait bientôt corriger, que j'ai contourné en déclarant un tableau de 13x1xlong,
- une variable utilisée dans un algo de hachage sur 64 bits que j'ai ramenée sur 32 bits (long au lieu de long long).

• GTC compile plus vite et produit un code plus petit que TIGCC.


Pourquoi parler de compilateur "obsolète" ou "jouet" quand on constate que les deux rivalisent ?

(il me semble que c'est à propos d'ETP que Kevin parlait de compilateur "jouet", tu dois confondre)

Dans ce cas, remplaçons "jouet" par "obsolète"

Thibaut (./47) :
- une variable utilisée dans un algo de hachage sur 64 bits que j'ai ramenée sur 32 bits (long au lieu de long long).

Dans la version TIGCC aussi? Parce que les opérations sur les long long prennent évidemment plus de place que les opérations sur les long!

Mhh.. pour les tests tu devrais pas simplement regarder le fait que ca compile et la taille du binaire. C'est pas fair pour tigcc.
En utilisant les options avancees sous les deux logiciels, tu devrais faire des tests de rapidite de code produit aussi. Pollux a un compilo avec des options de bases tres specifiques d'apres ce que j'ai compris (ca se comprend vu que c'est un compilo oncalc).

J'ai voulu me baser sur la taille, car c'est ce qui importe à Kevin.
Promis, la prochaine fois je m'attelle à la vitesse.

Pour les options, je te renvoie au ./46

Kevin : Oui, et d'ailleurs ça change la taille du binaire de quelques octets seulement.

Nan, mais les options ne sont pas un problemes: tigcc permet de generer du code different (optimiser ou pas etc.). gtc ne permet pas de faire varier les options je pense et est de base optimise pour la taille de generation de code.
Donc, afin de ne pas avoir un comparatif genre gtc pootre et tigcc c'est de la merde, autant ajouter aussi la vitesse de code avec les options -O3 etc. de tigcc, afin d'avoir une vue plus globale des resultats

nEUrOO (./53) :
Donc, afin de ne pas avoir un comparatif genre gtc pootre et tigcc c'est de la merde, autant ajouter aussi la vitesse de code avec les options -O3 etc. de tigcc, afin d'avoir une vue plus globale des resultats

Mais non, les options ne *surtout* pas être changées ! Ahlalala tu n'as rien suivi, toi

D'autant que le dévelopeur occasionel il cherche un truc qui compile, pas un QCM d'options pour un compilo...

Ça, c'est bien vrai.... je me suis jamais emmerdé à jouer avec les options de tigcc... sauf quand elles faisaient bugguer mes programmes, évidemment

D'ailleurs, c'est hors-sujet, mais Einstein plante actuellement alors qu'il fonctionnait avec TIGCC 0.94. Je soupçonne un stack overflow dans la fonction d'affichage des menus, qui est récursive.
Je vais vérifier que ça ne vient pas d'une modif dans les sources, mais j'en doute puisque ça fonctionne avec GTC.

Kevin : Avec TIGCC 0.95 et ses options par défaut, la pile est plus sollicitée qu'avec TIGCC 0.94 ?

(il faut y aller quand même pour faire un stack overflow... T'es sûr que ça ne serait pas plutôt des petits hacks ou du code pas super propre de ton côté ?)

Je vais vérifier. Mais je pense que quelque chose a changé entre la 0.94 et la 0.95.

oui le support de tes "hacks" n'es tplus garantit, Comme quoi TIGCC n'est pas backward compatible