Le compilateur GTC est-il mauvais ? - Page 4

euh, ben non, en tout cas chez moi ça marche très bien y pas de fichier graph.h dans le répertoire Include, mais #include <graph.h> est bien transformé par le compilo en #include <tigcclib.h>

C'est codé en dur ? Un fichier qui listerait les équivalences serait peut-être mieux, pour suivre d'éventuelles évolutions dans la structure de la bibliothèque de TIGCC ? (nouveaux headers...)

de toute façon nouveaux headers => nouvelle release => pas d'inconvénient à recompiler... si pour une autre raison quelqu'un veut rajouter un header qui redirige vers tigcclib.h, il suffit de créer un simple .h qui le fait ; à mon avis c'est plus propre que de devoir exposer/documenter/utiliser une interface spécifique à GTC

Pollux (./93) :
de toute façon nouveaux headers => nouvelle release

nouvelle release de GTC ? Pour la version PC le principe me paraît bon, mais pour la version embarquée le raisonnement est dangereux. Le jour où le support du SDK sera abandonné par TI (si ce n'est pas déjà le cas), il ne sera plus possible de mettre à jour GTC on calc.

Le principe d'un fichier externe, listant les headers à considérer comme faisant partie de tigcclib.h, me paraît plus juste et plus prudent. En effet, le système actuel, où les équivalences sont codées en dur, n'est pas un comportement très "standard" pour un compilateur C. Le principe le plus standard est à mon avis celui qui consisterait à avoir simplement un .h pour chaque header de la lib (le .h ne ferait alors rien d'autre qu'un "#include <tigcclib.h>").

C'est pour une question de vitesse que tu as choisi de faire comme tu fais là ?

Je viens de découvrir qu'il existait une version PC de GTC.

Thibaut (./94) :
Le jour où le support du SDK sera abandonné par TI (si ce n'est pas déjà le cas), il ne sera plus possible de mettre à jour GTC on calc.

D'ailleurs il serait ptet temps de pousser TI a fournir les outils pour generer soit meme des app flash signé... (comme pour les 83+ et autres 84...)ok

Mais à quoi ça sert de signer des applications si tout le monde peut le faire ?
A la base, ce système a été mis en place pour empêcher n'importe qui de coder-installer n'importe quoi, non ?

non

./97: tout le monde ne peut pas faire des apps flashs non

C'est à dire ?
Dans le monde du coding sur Z80, TI fournit la moulinette pour signer aux personnes qui le demandent, si celles-ci semblent dignes de confiance à TI ?

./99 > il me semble que si, mais elles doivent être signées par TI... mais bon, c'est vrai que rien n'empêcherait de les signer soi-même, quitte à avoir un avertissement...

./101 oui tu peut mais tu as pas ce qu'il faut pour signer, alors que pour les 83/84+ ces infos on/avaient été donné que je sache

Ouais beau boulot Pollux
Peu importe si GTC est 2% inférieur à TIGCC ou l'inverse, les résultats sur les quelques projets testés sont du même ordre de grandeur...

Thibaut (./67) :
Tu rigoles ?

Non.
Les versions "stables" de TIGCC ne sont pas du tout mises à jour, et donc en général plus boguées que les bêtas. Je pense à changer la nomenclature après la 0.96 finale (faire des 0.96.0, 0.96.1, 0.96.2 etc. probablement), mais en attendant les bêtas sont ce qu'il faut utiliser.

Thibaut (./69) :
Voici un premier résultat concernant la vitesse d'exécution.

Si c'est toujours avec TIGCC 0.95, tes résultats sont sans intérêt, il faut mesurer avec la 0.96 Beta 8.

Pollux (./70) :
les ROM CALLs du mode EXE_OUT sont équivalents niveau performance à ceux du mode kernel

Ah, c'est comme les KERNEL_FORMAT_ROM_CALLS de ld-tigcc alors.

donc c'est plus performant que OPTIMIZE_ROM_CALLS et évidemment largement plus performant que USE_FLINE_ROM_CALLS

... mais aussi plus gros que tous les deux.

vince (./79) :

Joli troll...

Thibaut (./87) :
La conséquence de cette non spécialisation, c'est que le code produit est plus gros.

Avec le GCC 3 obsolète que tu as testé. Réessaie avec un GCC 4 (TIGCC 0.96 Beta 8)!

D'ailleurs, si on compare uniquement les codes objets générés par TIGCC et par GTC, GTC devance encore plus clairement TIGCC.

Idem, réessaie avec la 0.96 Beta 8.

(Beta 8 qui et obsolète je te ferais remarquer)

Pourquoi tu continues à recommander la 0.95 sur ton site alors que tu dis ici que les versions inofficielles sont meilleures ?
Y'a un truc pas logique là.

Il peut utiliser le CVS HEAD aussi hein. Mais ça ne devrait pas changer tellement de trucs du côté taille, ce sont avant tous des corrections pour des bogues qui ne se produisent pas souvent.

La 0.95 date de 2004 et utilise un GCC 3, c'est ridicule d'utiliser ça comme la mesure de la qualité d'optimisation de TIGCC!

Thibaut (./107) :
Pourquoi tu continues à recommander la 0.95 sur ton site alors que tu dis ici que les versions inofficielles sont meilleures ?Y'a un truc pas logique là.

Parce que ce truc est écrit sur le site depuis des années et n'a pas été changé?

À l'époque, j'ai demandé à Sebastian pourquoi cette formulation et il a dit que c'est parce que les versions officielles sont censées être uploadées dans l'archive principale de ticalc.org et qu'il n'avait pas envie de le faire pour chaque bêta. (Cela dit, je pense que c'est bien ce que je vais faire après la 0.96, je vais faire des 0.96.1 etc. et les uploader toutes sur ticalc.org.)

Pour ceux que ça intéresse, le plan est de sortir la 0.96 Beta 9 (dernière bêta), puis peu après la 0.96 officielle, et après passer sur des versions 0.96.1 etc. et/ou 0.97 etc. en vue d'une 1.00 avec KTIGCC 2.

Le compilateur GTC est-il mauvais ?

non

Bah, il est meilleur que le tien, c'est sûr.

Thibaut (./94) :
nouvelle release de GTC ? Pour la version PC le principe me paraît bon, mais pour la version embarquée le raisonnement est dangereux. Le jour où le support du SDK sera abandonné par TI (si ce n'est pas déjà le cas), il ne sera plus possible de mettre à jour GTC on calc.

Le jour où le support sera abandonné, il y aura des problèmes bien plus gênants que de devoir créer à la main un éventuel nouveau .h synonyme de tigcclib.h ! Et puis bon l'arrêt du support n'empêcherait pas les mises à jour, seulement il faudra utiliser un AMS patché plutôt que celui d'origine...

C'est pour une question de vitesse que tu as choisi de faire comme tu fais là ?

C'est juste histoire de pas se retrouver avec des tonnes de fichiers inutiles sur la calc... (c'est plus une question de bloat que de vitesse de compilation)

Kevin Kofler (./105) :

donc c'est plus performant que OPTIMIZE_ROM_CALLS et évidemment largement plus performant que USE_FLINE_ROM_CALLS

... mais aussi plus gros que tous les deux.

Non, c'est seulement un peu plus gros que USE_FLINE_ROM_CALLS (mais sachant que USE_FLINE_ROM_CALLS est ultra-lent...)

Pollux (./114) :
Et puis bon l'arrêt du support n'empêcherait pas les mises à jour, seulement il faudra utiliser un AMS patché plutôt que celui d'origine...

Tu sais faire un patch pour contourner la vérification des signatures? Du coup ça m'intéresse.

Kevin Kofler (./105) :

donc c'est plus performant que OPTIMIZE_ROM_CALLS et évidemment largement plus performant que USE_FLINE_ROM_CALLS

... mais aussi plus gros que tous les deux.

Non, c'est seulement un peu plus gros que USE_FLINE_ROM_CALLS (mais sachant que USE_FLINE_ROM_CALLS est ultra-lent...)

Alors il faudra que tu m'expliques le format utilisé...

Moi, pour un ROM_CALL relogé, je compte un jsr + le placeholder pour l'adresse absolue (6 octets), plus l'information de relogement. Et je ne vois pas comment faire aussi rapide que ça en moins de place.

strcat, strcpy, memcpy, etc, ne sont pas des appels en ROM ? Ce sont des fonctions souvent appelées, parfois dans des endroits critiques.

onur (./112) :

Le compilateur GTC est-il mauvais ?

non

Kevin Kofler (./113) :
Bah, il est meilleur que le tien, c'est sûr.

J'aimerais bien voir ton compilateur à toi, Kevin Tu nous as dit que tu en avais programmé un...

Kevin Kofler (./105) :

vince (./79) :

Joli troll...

Ca veut donc dire qu'on peut compter sur toi pour arrêter ta guéguerre stérile ? Si c'est le cas, bonne nouvelle !