GTC : un TIGCC sur votre calculatrice ? - Page 21

Tout à fait
J'aoute que malheureusement un des 2 camps est trop content de sa position dominante pour accepter une collaboration avec ceux qu'il voit comme des concurrents.

On ne peut pas "mettre ensemble" TIGCC et GTC. Leur structure est totalement différente. GTC est du "tout en une passe", GCC a des optimisations élaborées et utilise plusieurs représentations intermédiaires.

Si on arrêtait d'influencer nos posts par la haine envers le "concurrent", on pourrait parler sérieusement.

GTC utilise aussi plusieurs passes, mais elles se font à l'intérieur du même programme et sont plus ou moins entrelacées.

On pourrait "mettre ensemble" GTC et TIGCC en arrêtant de s'engueuler et en s'aidant :
- portage d'ExtGraph vers GTC (bénéfique pour la TICT)
- création d'un format de .tpr commun pour améliorer la portabilité (je dirais que c'est à Pollux de s'aligner sur votre format)
- citer GTC dans la documentation de TIGCC, par exemple dans la FAQ, à une question du genre : "Is it possible to programming in C on calculators ?"
- arrêter les remarques méchantes "GTC est vraiment de moins moins intéressant parcequ'il ne fait pas X", mais apporter plutôt des suggestions amicales
- ...

Je le sais bien mais c'est franchement dommage!

(excusez mon anglais pourrave )

C'est solution serais vraiment bien. Il faut plutôt aider au développement de TIGCC et GTC en incluant dans GTC des fonctions que TIGCC a et inversement!

Pratiquement toutes les fonctions de TIGCC sont déjà dans GTC Il n'y a qu'à voir le tout premier post du topic et les différents tests effectués au cours des pages (compilation de mon IA, de TILTmaze, et un autre truc de la TICT dont Pollux parle).

J'ai énuméré ce qui me semble le plus important dans le post #602, mais j'ai pû oublier des choses.

t'as oublié un truc, Thibauts, dires que le fait que GTC ne gère pas un truc que TI-GCC fait est un moins de GTC et dire que le fait que GTC gère des truc que TI-GCC fait pas est une incompatibilité de GTC

Je l'ai dit à travers le dernier point.

ça se rapproche, mais c pas tous à fait pareils (remarque méchante<=>différence entre les plus ou moins de GTC face à TI-GCC)

Et puis comme ils sont de mauvaise foi (à moins que mon post ait fait effet ), il te répondront que les manques de TIGCC ne sont pas des incompatibilités parceque TIGCC est un standard
Moi je dis non, parceque GTC pourrait devenir un standard (ils ont peur de ça nos petits messieurs), voir le même standard si les deux équipes coopèrent.

Bah... perso, je pense que j'utiliserais plus que GTC, vu que j'aime pas programmer on-pc, donc déjas, ce serat mon ti standart perso:]

Thibaut
a écrit : GTC utilise aussi plusieurs passes, mais elles se font à l'intérieur du même programme et sont plus ou moins entrelacées.

Elles sont tellement entrelacées que c'est en fait une seule passe.

- arrêter les remarques méchantes "GTC est vraiment de moins moins intéressant parcequ'il ne fait pas X", mais apporter plutôt des suggestions amicales

On lui en fait depuis des mois, des suggestions. Mais il ne les écoute pas. Ça fait longtemps que je lui dis:
* d'arrêter de rajouter des extensions de langage à GTC qu'il pense lui-même être inimplémentables dans GCC (et de retirer celles qui y sont déjà)
* de passer le temps qu'il passe à rajouter ces extensions à implémenter les fonctionnalités de TIGCC qui manquent à GTC
mais il s'en fiche.

MacIntoc a écrit :
t'as oublié un truc, Thibauts, dires que le fait que GTC ne gère pas un truc que TI-GCC fait est un moins de GTC et dire que le fait que GTC gère des truc que TI-GCC fait pas est une incompatibilité de GTC

* TIGCC était là avant. Donc c'est à celui venu après d'être compatible avec ce qu'il y a déjà.
* Nous avons toujours documenté toutes nos extensions de langage. Pollux, lui, m'a pondu une liste largement incomplète à ma demande explicite il y a quelques jours.

ouais, mais bon, pour la doc, on peut pas dire que vous soyer tous seul. Il peut pas à la fois programmer et faire une doc. Je pense que la programmation est prioritaire. Une doc sans programme ne sert pas à grand-chose. Et puis rien ne vous empèche à l'aider à faire la doc

pour le premier point, c vrai, mais ce serait plutot les manques de GTC qui sont les incompatibilité, et les plus des avantages, et pas les manques les défauts et le plus les incompatibilités.

Tssss. La liste viendra avec la documentation de GTC. Votre documentation n'est pas venue tout de suite avec TIGCC.

Si Pollux n'ajoute pas les extensions que tu lui suggères, c'est peut-être parcequ'elles demandent de trop grosses modifications. J'en reviens à dire encore une fois : Pollux a déjà énormément bossé, et évitez de le faire chier sur des choses que vous seriez incapables de faire.
Choisissez plutôt la sympathie (un sentiment que Kevin semble ignorer) pour collaborer.

> c'est à celui venu après d'être compatible avec ce qu'il y a déjà.
Quand ton "concurrent" a de meilleures idées que les tiennes, il faut surpasser ta fierté pour accepter de le reconnaître, et de les reprendre dans TIGCC (== collaboration).

MacIntoc : pour ton premier paragraphe, je te répond qu'ils n'ont pas le SDK, alors ils sont mal barrés pour rédiger une doc

Pour le second, I agree with you.

pkoi faire le sdk ???

Thibaut
a écrit : Tssss. La liste viendra avec la documentation de GTC. Votre documentation n'est pas venue tout de suite avec TIGCC.

Les extensions de GCC ont toujours été documentées, et d'ailleurs leur support n'était pas une décision à nous, mais des développeurs de GCC. Donc c'est sur eux qu'il faut gueuler si vous n'êtes pas contents.
Quant aux trucs qu'on a rajouté nous, c'était:
* nombres binaires
* -fno-auto-octals
* passage par registres
* compatibilité antérieure (chaînes de caractère multi-lignes, -fglobal-cast-constructors (activé par défaut))
et dans tous les cas, c'était suite à la demande d'utilisateurs. En particulier, pour le passage par registres, tout le monde ici nous gueulait dessus pour qu'on l'implémente enfin. Et dans tous les cas, ça a été documenté dès son introduction.
Et les conditions sont les mêmes pour nous et pour l'équipe de GCC: On n'implémente en aucun cas une extension sans la documenter!

Si Pollux n'ajoute pas les extensions que tu lui suggères, c'est peut-être parcequ'elles demandent de trop grosses modifications.

Et pourquoi penses-tu que je n'ai pas envie de rajouter les extensions que Pollux, lui, a sorti de je ne sais pas où? Parce que je suis méchant et que je veux que TIGCC ne comprenne pas les sources écrites pour GTC??? Ben, évidemment que ce n'est pas le cas. Mais ces extensions demandent d'énormes modifications à GCC! Et je ne vous parle pas du travail qu'on a déjà pour porter notre patch vers des versions futures de GCC. Je vous laisse imaginer ce que ça va donner si on implémente ces extensions stupides élaborées en secret par Pollux sans jamais discuter de la faisabilité pour d'autres compilateurs avec les mainteneurs de ces autres compilateurs.

la sympathie (un sentiment que Kevin semble ignorer)

Et si tu arrêtais de m'insulter gratuitement??? C'est parce que tu as un accord avec XDanger de ne pas l'insulter que tu te déchaînes sur moi?

> c'est à celui venu après d'être compatible avec ce qu'il y a déjà. Quand ton "concurrent" a de meilleures idées que les tiennes, il faut surpasser ta fierté pour accepter de le reconnaître, et de les reprendre dans TIGCC (== collaboration).

Si c'était faisable et si ses idées avaient été documentées correctement et discutées publiquement, ça serait déjà fait.

J'adore ces topics, c'est marrant tous le topics ou kevin poste sont pourri dans l'heure qui suit, lol

> ces extensions stupides
Tu pourrais réfléchir avant d'ouvrir ta gueule ! Tu te sens malin à démonter ceux qui font des projets aussi gros qui serviront à énormément de monde ?

> Et si tu arrêtais de m'insulter gratuitement ???
Et si tu arrêtais tes casses gamines contre GTC ?

> Si c'était faisable et si ses idées avaient été documentées correctement et discutées publiquement, ça serait déjà fait.
Toujours est-il qu'elles sont bonnes. Certainement pas stupides.
Si tu acceuillais un tel projet plus gentillement, Pollux aurait peut-être plus envie de discuter avec toi.

Personnellement, j'ai du mal à faire des efforts de dialogue quand j'ai un mec comme toi en face, qui passe son temps à faire chier le peuple avec ses idées, qui se prend pour le chef de la communauté, en emmerdant ceux qui n'ont aucun compte à rendre mais qui ont la sympathie de mettre leur passion au service d'une communauté.

alexis : Kevin est tellement sympathique

Thibaut a écrit :
> ces extensions stupides Tu pourrais réfléchir avant d'ouvrir ta gueule ! Tu te sens malin à démonter ceux qui font des projets aussi gros qui serviront à énormément de monde ?

Je ne démonte pas le projet, juste les quelques extensions de langage stupides que Pollux y a mises.
Que le projet soit gros ou non et qu'il serve à énormément de monde ou non ne change rien à la stupidité ou non des extensions de langage implémentées par Pollux! Les as-tu lues au moins?
Tu te laisses tellement entraîner par ce projet que tu laisses totalement de côté ton bon sens et que, dès que quelqu'un "ose" critiquer un aspect particulier de ce projet, tu sens qu'on "démonte" ce projet en entier. Ouvre tes yeux!

> Et si tu arrêtais de m'insulter gratuitement ??? Et si tu arrêtais tes casses gamines contre GTC ?

Tu n'as pas compris le sujet de ma critique. Elles ne sont pas dirigées "contre GTC", mais contre un défaut particulier de GTC (le manque de compatibilité, et cela dans les 2 sens: fonctionnalités du GNU C99 non implémentées, extensions par rapport au C99 ISO ou GNU rajoutées sans penser à la compatibilité avec TIGCC).

> Si c'était faisable et si ses idées avaient été documentées correctement et discutées publiquement, ça serait déjà fait.
Toujours est-il qu'elles sont bonnes. Certainement pas stupides. Si tu acceuillais un tel projet plus gentillement, Pollux aurait peut-être plus envie de discuter avec toi.

Je n'ai jamais "mal accueilli" son projet. Ce n'est que toi qui t'imagines cela.

ce que je comprend pas, c pkoi GTC devrfait être compatible avec TI-GCC et que TI-GCC ne devrait pas êter compatible avec GTC

Ta réponse me fait bien sourire

Je te demande alors pourquoi tu as l'intention de déconseiller GTC à sa sortie, en prétendant qu'il ne mérite pas d'être utilisé à cause de ce qu'il a en moins.
Un compilo sur calc ne peut pas supporter tout ce qu'a un compilo sur PC. GTC est mille fois plus intéressant que CC.
Si tu as encouragé CC à sa sortie (au point d'avoir porté un utilitaire pour le K&R), tu n'as alors pas à démonter GTC à sa sortie : il n'a que des choses en plus, et il est carrément plus compatible !

Voilà pourquoi j'ai le sentiment que GTC te dérange : tu n'es pas logique.

MacIntoc : parceque TIGCC est bien implanté dans les moeurs. Mais, je l'ai déjà dit une fois, j'espère de tout coeur que la situation s'inversera, que le monde des programmeurs basculera de l'enfer vers la liberté

J'ai passé toute la journée à corriger les bugs de GTC on-calc Encore désolé, mais je ne crois pas pouvoir sortir GTC ce week-end, mais j'espère pouvoir le sortir un week-end après les vacances.


> Je trouve le projet de GTC très interessant mais le top serait de réunir TIGCC et GTC pour faire un compilateur de tonnerre avec des fonctions avancés...
C'est extrêmement difficile. GTC et TIGCC fonctionnent très différemment (c'est surtout dû au fait que GTC a la contrainte d'être compatible on-calc, tandis que GCC a la contrainte d'être portable pour d'autres plateformes que le 68k - résultat, GTC ne peut pas se permettre de faire les optimisations extrêmement coûteuses en temps et en mémoire, alors que TI-GCC "loupe" peut-être certaines optimisations parce que son système d'optimisation est trop généraliste).

> > XDanger a quand même fini par reconnaître que GTC était un projet très intéressant
> Oui. Mais plus je découvre de manques à GTC, moins je le trouve intéressant...
Ca dépend si tu veux programmer on-calc ou pas...

C'est en effet une idée très intelligente (non, je ne suis pas ironique). Les fonctions du tonnerre sont toutes du côté de TIGCC, mais il manque une version on-calc à TIGCC. C'est sûr que les deux projets sont complémentaires: TIGCC pour la puissance des fonctions on-pc, GTC pour la possibilité de programmer on-calc (il manque quelques trucs à GTC, et la taille de la mémoire est limitée on-calc...)

Le problème c'est que si on les mélangeait on aurait un compilo PC-only moins optimisé (bon j'exagère, mais le problème c'est que les inconvénients s'ajoutent, et pas les avantages)

Le seul grand mérite de GTC, c'est d'avoir une version on-calc. Mais elle a ses limites: taille des headers et des libs statiques.

Excuse-moi, mais la majeure partie de la TI-GCC Lib tient en 40 ko
Et Extgraph tient en 36 ko non compressé alors que 90% des fonc ne servent pas (pour un programme donné, je précise)...

> Il faut aussi ajouter à cela que comme le code du compilateur proprement dit dans les versions PC et calc est le même, d'après ce qu'il avait dit, la version PC se trouve de fait en-dessous de TIGCC en termes de fonctions.
Oui. Mais les bench montrent que la différence n'est pas très significative.

> Sur GTC, la vitesse de compilation est peut-être plus élevée (on verra les benchs...)
Tu peux dire "certainement"...

> et la taille plus faible (Kevin a récemment diminué de façon très importante la taille de GCC en compilant sans les options de debug, ça risque aussi d'accélérer la compilation...)
Certainement aussi...

> mais est-ce que ces arguments tiennent vraiment debout (à moins d'être sur des PC totalement dépassés depuis au moins 4 ans) ?
La vitesse de compilation est utile pour le débogage, après rien n'interdit de finaliser avec TI-GCC. Mais par contre la taille on s'en fout effectivement
Et je le répète, GTC n'est pas principalement destiné à être on-PC.

On ne peut pas "mettre ensemble" TIGCC et GTC. Leur structure est totalement différente. GTC est du "tout en une passe", GCC a des optimisations élaborées et utilise plusieurs représentations intermédiaires.

GTC n'est pas du "tout en une passe"
GTC utilise des arbres pour se réprésenter les expressions et les structures de contrôle, puis fait tout un tas d'optimisations sur les arbres (ça fait plein de passes ), génère un code intermédiaire à partir de ces arbres, puis génère de l'ASM à partir de ce code un intermédiaire.
Et tu as l'air de dire que "plus il y a de passes, mieux c'est" - mais il n'y a pas que le nombre de passes, il y a aussi la qualité des algos. Par exemple, mon packer on-calc compresse le fichier en une seule passe (eh oui!), ce qui ne l'empêche pas de n'avoir qu'1,2% de différence en taille dans le pire des cas avec TTPack si on restreint la fenêtre LZ à la même taille qu'on-calc, mémoire oblige (i.e. 3% au total sur des gros fichiers, bcp moins sur des petits).

> GTC utilise aussi plusieurs passes, mais elles se font à l'intérieur du même programme et sont plus ou moins entrelacées.
En quelque sorte, oui

> création d'un format de .tpr commun pour améliorer la portabilité (je dirais que c'est à Pollux de s'aligner sur votre format)
Bonne idée

> Elles sont tellement entrelacées que c'est en fait une seule passe.

Tu m'énerves, Kevin, à tjs vouloir parler de ce que tu ne sais pas! C'était la même chose plusieurs fois dans ce topic (regparm, etc...), et je ne pouvais pas te corriger puisque je n'étais pas chez moi
Non, cf plus haut

> On lui en fait depuis des mois, des suggestions. Mais il ne les écoute pas. Ça fait longtemps que je lui dis:
> * d'arrêter de rajouter des extensions de langage à GTC qu'il pense lui-même être inimplémentables dans GCC (et de retirer celles qui y sont déjà)
Ces extensions sont présentes depuis pas mal de temps. Pour ce qui est de l'implémentabilité, effectivement cdefined() risque d'être très difficile à rajouter dans TI-GCC, et je ne le mettrais peut-être pas dans GTC - ou alors seulement dans des fonctions internes à la lib, pour éviter des hacks sales du style SYMSTR/SYMSTR_CONST.
Par contre, #macro et le changement au cours d'un fichier des options de compilations sont vraiment utiles et sont à mon avis parfaitement implémentables dans TI-GCC (même si je ne connais pas vraiment les détails de la structure interne de GCC). J'ajoute que le changement d'options de compilation ne constitue pas une incompatibilité puisqu'on peut très bien faire en sorte que TIGCC les ignore. #macro permet, entre autres, d'éviter plein de hacks sales.

> de passer le temps qu'il passe à rajouter ces extensions à implémenter les fonctionnalités de TIGCC qui manquent à GTC
> mais il s'en fiche.
Je ne m'en fiche pas. Je fais tout ce qui est en mon pouvoir pour avoir un compilo rapide et léger qui puisse fonctionner sur calculatrice, tout en maintenant une bonne compatibilité avec TIGCC. Je suis désolé, mais certaines extensions de TIGCC ne seront jamais dans GTC (à moins que les TI passent à 1 Mo de RAM et un 68k à 30 MHz )

> TIGCC était là avant. Donc c'est à celui venu après d'être compatible avec ce qu'il y a déjà.
Un compilo on-calc ne peut pas se le permettre, cf réponse précédente.

> Nous avons toujours documenté toutes nos extensions de langage. Pollux, lui, m'a pondu une liste largement incomplète à ma demande explicite il y a quelques jours.
Je n'ai pas eu le temps de rédiger une doc complète
Pour ce qui est des extensions de langage, je ne trouve pas la doc du 'register var asm("rn")' dans TI-GCC. De même, je ne vois nulle part à quels registres sont affectées les variables pour __regparm__ (mais j'ai peut-être mal cherché...)

> Je vous laisse imaginer ce que ça va donner si on implémente ces extensions stupides élaborées en secret par Pollux sans jamais discuter de la faisabilité pour d'autres compilateurs avec les mainteneurs de ces autres compilateurs.
Tu crois sincèrement que le préprocesseur de GCC va évoluer fondamentalement? #macro ne demande a priori que des légères modifications dans le préprocesseur.

MacIntoc a écrit :
ce que je comprend pas, c pkoi GTC devrfait être compatible avec TI-GCC et que TI-GCC ne devrait pas êter compatible avec GTC

Parce que:
* TIGCC était là avant GTC, et GCC (sur lequel TIGCC est basé) encore avant.
* GCC n'implante pas n'importe quoi comme extensions. Pollux, lui, a rajouté à GTC tout ce qui lui est passé par la tête.
* Les extensions de GCC étaient le fruit de consultations publiques. Pollux, lui, a développé ses extensions en secret.
* Pollux refuse de rendre GTC compatible même avec le standard ISO C99. Cf. déclarations dans une boucle for non supportées par GTC.
* Comment étions-nous censés implémenter des extensions dont nous avons ignoré l'existence jusqu'à il y a quelques jours??? Pollux, lui, connaissait très bien nos extensions parce qu'elles étaient discutées en public avant leur introduction et documentées dès leur introduction.

Thibaut
a écrit : Je te demande alors pourquoi tu as l'intention de déconseiller GTC à sa sortie, en prétendant qu'il ne mérite pas d'être utilisé à cause de ce qu'il a en moins.

Je n'ai pas "l'intention de déconseiller GTC à sa sortie", je veux juste que les gens soient au courant des limitations de GTC et pas seulement de ta propagande et de celle de Pollux.

Un compilo sur calc ne peut pas supporter tout ce qu'a un compilo sur PC. GTC est mille fois plus intéressant que CC.

Un compilateur développé sur plusieurs années a vraiment intérêt à être plus intéressant que CC, sinon il partirait à la poubelle direct.

Thibaut a écrit :
MacIntoc : parceque TIGCC est bien implanté dans les moeurs. Mais, je l'ai déjà dit une fois, j'espère de tout coeur que la situation s'inversera, que le monde des programmeurs basculera de l'enfer vers la liberté

Vive l'objectivité...

> TIGCC était là avant GTC, et GCC (sur lequel TIGCC est basé) encore avant.
cf post précédent (que tu n'as pas encore lu apparemment)

> GCC n'implante pas n'importe quoi comme extensions. Pollux, lui, a rajouté à GTC tout ce qui lui est passé par la tête.
N'importe quoi... cf post préc.

> Les extensions de GCC étaient le fruit de consultations publiques. Pollux, lui, a développé ses extensions en secret.
Je ne me rappelle pas avoir vu la moindre de ces discussions...

> Pollux refuse de rendre GTC compatible même avec le standard ISO C99. Cf. déclarations dans une boucle for non supportées par GTC.
C'est, entre autres, pour ne pas encourager les programmeurs à faire un code vraiment horrible.

> Comment étions-nous censés implémenter des extensions dont nous avons ignoré l'existence jusqu'à il y a quelques jours???
Ah bon, tu me l'avais demandé avant?
Et sinon comment suis-je censé implémenter toutes ces fonctions "top-secret" qui ne sont censées être implémentées que dans TIGCC 0.95 ? Ce n'est pas si public que ça...

> Pollux, lui, connaissait très bien nos extensions parce qu'elles étaient discutées en public avant leur introduction et documentées dès leur introduction.
cf plus haut J'ai découvert à chaque fois chaque extension à sa sortie...

Kevin Kofler a écrit :
Parce que:
* TIGCC était là avant GTC, et GCC (sur lequel TIGCC est basé) encore avant.

L'ancienneté n'est pas une preuve de standart, en informatique, ce serait plutot même le contraire, à la limte.

* GCC n'implante pas n'importe quoi comme extensions. Pollux, lui, a rajouté à GTC tout ce qui lui est passé par la tête.

Je vois pas ce qu'il y a de mal à ça, si sa apporte kkchose au programme. Je pense pas qu'il se soit pris la tête et a gaspiller de la place si ça ne valait pas le coup.

* Les extensions de GCC étaient le fruit de consultations publiques. Pollux, lui, a développé ses extensions en secret.

je suis d'accord sur ce point. Mais ça aurait ralentis beaucoup l'avancement de la programmation (déjas qu'on l'attend depuis un moment) s'il av fallut parler de chaques extensions pendant 2 mois sur 10 forums (pour que tous le monde soit au courant).

* Pollux refuse de rendre GTC compatible même avec le standard ISO C99. Cf. déclarations dans une boucle for non supportées par GTC.

Il doit y avoir une raison valable à ça ?

* Comment étions-nous censés implémenter des extensions dont nous avons ignoré l'existence jusqu'à il y a quelques jours??? Pollux, lui, connaissait très bien nos extensions parce qu'elles étaient discutées en public avant leur introduction et documentées dès leur introduction.

Rien ne vous empèche de rattraper le temps perdu, au lieu de dire que c extensions sont stupide.

Dans ce que tu dis, il y a au moins la reconnaissance d'un fait patent: les références et les standards du monde TI, peu de personnes sont capables de les faire utiliser... et la TIGCC Team en fait partie (Pollux et toi, entre autres, le savez très bien...).

ce que VOUS considérez comme des standard...
tout le monde ne considére pas certaines de ces choses comme des standard