GTC : un TIGCC sur votre calculatrice ? - Page 4

- Pas de passage d'argument par paramètres

Ca c'est dommage. Et ça ne va pas dans le sens de l'efficacité, autant en taille qu'en vitesse. Le bench qu'a posté Thibaut montre que le code est environ 5% plus petit, mais il est aussi plus de 10% plus lent (mais c'est inline qui est responsable, et pas le passage par paramètres)...

- Plein de truc inutiles dont 98% des programmeurs C ce fichent totalement et dont on peut facilement se passer.

Certes, mais quels sont exactement ces trucs inutiles ? C'est pour ça que je voudrais que Pollux s'exprime.

Voyons un peu une partie des extensions du GNU C (dont une partie est dans le C99...):
- les cast constructors/compound literals (très pratique et gagne du temps et de la place si les paramètres sont constants)
- les nested functions (permet entre autres d'éviter de passer plein de paramètres sur la pile dans certains cas, les nested functions héritant des paramètres et des variables des fonctions qui sont juste au-dessus: dans tthdex, ça m'évite de passer 5 paramètres à une fonction...)
- l'ASM inline avec opérandes C (une partie qui est loin d'être négligeable de tthdex l'utilise pour être plus rapide et plus petit)
- le keyword inline (ça peut améliorer la vitesse, *légèrement*)
- les attributs de fonctions ou de variables ( __attribute__((__stkparm__)) ou __regparm__(n), et plein d'autres attributs...)
- les tableaux de taille nulle ou variable (comment définissez-vous de manière simple la structure BITMAP d'AMS sans les tableaux de taille variable ?)
- conditionals with omitted operands (pratique, même si ça n'est pas indispensable)
- les types 'enum' incomplets (une bonne partie de TIGCCLIB est basée là-dessus...)
...
(et dans une moindre mesure)
- initialisation de variables avec des paramètres non-constants, inconnus au compile-time
- typecast dans le type union
- long longs
...

Il ne faut pas se dire compatible avec TIGCC si l'une quelconque des nombreuses extensions citées plus haut, qui sont utiles et vont dans le sens de l'efficacité, n'est pas supportée (le passage par registres ne fait pas partie de GCC, je le sais).

Voila ce qui manque a TIGCC:
- Compilateur leger et optimiser pour la calc
- Programmation On-Calc

Certes. Cependant, je continue à me demander si la majorité des personnes est prête à programmer on-calc (tout le monde sait que faire planter VTI n'a pas de conséquences; mais faire planter une calculette réelle peut en avoir)... Même si la quasi-absence de compilateur C on-calc ne donne aucune statistique sur la proportion de personnes qui veulent programmer on-calc.

Bah déjas, y a moi
G pas assez de place sur mon compre au lycée pour installer TI-GCC

Uther Lightbringer a écrit :
Voila ce qui manque a GTC: - Pas de passage d'argument par paramètres

Tu veux dire "par registres"? Si oui, c'est un assez grand défaut. Beaucoup de programmeurs utilisent le passage par registres depuis qu'il a été introduit dans les bêtas de TIGCC 0.94.

- Pas de version Linux(a ce que je sache)

Également un défaut.

- Plein de truc inutiles dont 98% des programmeurs C ce fichent totalement et dont on peut facilement se passer.

C'est justement la liste précise de ces trucs que tu juges inutiles qu'on veut!

Voila ce qui manque a TIGCC:
- Compilateur leger et optimiser pour la calc - Programmation On-Calc

GCC n'a jamais été fait pour tourner on-calc et ne le sera jamais.
Un compilateur du calibre de GCC est impossible à faire tourner sur une calculatrice.

Voyons un peu une partie des extensions du GNU C (dont une partie est dans le C99...):
- les cast constructors/compound literals (très pratique et gagne du temps et de la place si les paramètres sont constants)
- les nested functions (permet entre autres d'éviter de passer plein de paramètres sur la pile dans certains cas, les nested functions héritant des paramètres et des variables des fonctions qui sont juste au-dessus: dans tthdex, ça m'évite de passer 5 paramètres à une fonction...)
- l'ASM inline avec opérandes C (une partie qui est loin d'être négligeable de tthdex l'utilise pour être plus rapide et plus petit)
- le keyword inline (ça peut améliorer la vitesse, *légèrement*)
- les attributs de fonctions ou de variables ( __attribute__((__stkparm__)) ou __regparm__(n), et plein d'autres attributs...)
- les tableaux de taille nulle ou variable (comment définissez-vous de manière simple la structure BITMAP d'AMS sans les tableaux de taille variable ?)
- conditionals with omitted operands (pratique, même si ça n'est pas indispensable)
- les types 'enum' incomplets (une bonne partie de TIGCCLIB est basée là-dessus...)
...
(et dans une moindre mesure)
- initialisation de variables avec des paramètres non-constants, inconnus au compile-time
- typecast dans le type union
- long longs ...

Franchement ses fonctions sont peut-être utiles dans certain cas mais je n'en connais pas la moitié et ca m'a jamais empeché de programmer.

Il ne faut pas se dire compatible avec TIGCC si l'une quelconque des nombreuses extensions citées plus haut, qui sont utiles et vont dans le sens de l'efficacité, n'est pas supportée (le passage par registres ne fait pas partie de GCC, je le sais).

Je ne demande pas 100% de compatibilité: c'est titanesque. La compatibilité C ANSI me suffit largement(et comme cela le prog peuvent sans problème passer d'un compilateur a l'autre), cependant, plus il supportera d'extensions, mieux ca sera. Beaucoup de gens travail en K&R et se débrouillent très bien avec! alors décreter que GTC ne vaut rien parcequ'il ne supporte pas 100% des extentions de GCC, ca me faire rire.

Tu veux dire "par registres"? Si oui, c'est un assez grand défaut. Beaucoup de programmeurs utilisent le passage par registres depuis qu'il a été introduit dans les bêtas de TIGCC 0.94.

En effet oui je voulais parler de passage par registre(c'est corrigé). C'est certes génant pour les programme très optimisés mais même sur TIGCC leur utilisation et toute récente et a part genlib je ne connais pas un seul programme qui y gagne vraiment

Certes. Cependant, je continue à me demander si la majorité des personnes est prête à programmer on-calc (tout le monde sait que faire planter VTI n'a pas de conséquences; mais faire planter une calculette réelle peut en avoir)... Même si la quasi-absence de compilateur C on-calc ne donne aucune statistique sur la proportion de personnes qui veulent programmer on-calc.

certes mais si on a une rom > 2.05, les conséquences des plantages sont moindres! Malgé les limitation de CC je l'utilise pas mal et j'en suis satisfait. En plus GTC semble corriger tous les défaults que je trouve a CC.

GCC n'a jamais été fait pour tourner on-calc et ne le sera jamais. Un compilateur du calibre de GCC est impossible à faire tourner sur une calculatrice.

C'est bien la que réside son principal défault: c'est un prog mastodonte: CC compile bien plus vite que TIGCC sur mon 133(même en ligne de commande). et le faire tourner sur calculette n'est pas imaginable car GCC n'a pas été prévu pour ca.

La compatibilité C ANSI me suffit largement(et comme cela le prog peuvent sans problème passer d'un compilateur a l'autre), cependant, plus il supportera d'extensions, mieux ca sera. Beaucoup de gens travail en K&R et se débrouillent très bien avec! alors décreter que GTC ne vaut rien parcequ'il ne supporte pas 100% des extensions de GCC, ca me faire rire.

Les programmes, eux, ne peuvent tourner que sur un système très spécifique qui est une TI-68K avec AMS... Donc faire passer un programme d'un compilateur à un autre me paraît un peu dérisoire...
Si tu ne veux pas profiter des extensions les plus puissantes de GCC, tant pis pour toi. Ce que je sais, c'est que beaucoup de programmes qui se compilent actuellement parfaitement avec TIGCC ne passeront pas ou très mal avec GTC. Je n'appelle pas ça un excellent compilateur, désolé.

C'est certes génant pour les programme très optimisés mais même sur TIGCC leur utilisation et toute récente et a part genlib je ne connais pas un seul programme qui y gagne vraiment

Ca fait des mois que c'est utilisé... Genlib n'est pas le seul truc à bénéficier du passage par registres, n'importe quel programme peut en bénéficier..

C'est bien la que réside son principal défault: c'est un prog mastodonte: CC compile bien plus vite que TIGCC sur mon 133(même en ligne de commande). et le faire tourner sur calculette n'est pas imaginable car GCC n'a pas été prévu pour ca.

Je pense que peu de monde a prévu que quelques personnes pourrait utiliser un truc aussi puissant sur un hardware aussi faible !

Uther Lightbringer > Voila ce qui manque a GTC: - Pas de passage d'argument par registre
ON PEUT PASSER LES PARAMETRES PAR REGISTRES avec GTC !


XDanger > Le bench qu'a posté Thibaut montre que le code est (...) plus de 10% plus lent (mais c'est inline qui est responsable, et pas le passage par paramètres)...
Les inline ont été supprimés pour les deux compilateurs ! Pour pouvoir comparer, il faut que ça soit comparable

> Je n'appelle pas ça un excellent compilateur, désolé.
Si je réagissais comme vous face au Shl d'Orion, vous comprendriez sûrement comment vous êtes.....................
GTC est un très bon compilateur, rapide, produisant du code efficace, oncalc, supportant énormément de choses. Sauf pour quelques syntaxes relevant du standard C99, il peut tout compiler.

Pollux bosse dessus depuis 3 ans, il mérite des encouragements, sont courage est admirable, le résultat encore plus. Vous savez au moins de quoi il est partit précisément ?
Ce n'est pas du rejet qu'il mérite !
.......................lamentables.

ON PEUT PASSER LES PARAMETRES PAR REGISTRES avec GTC !

Génial! Il me manque plus que tu m'annonce un version Linux et je suis comblé. C'est bizarre il me semblait que PpHd avais dit que GTC ne supportait pas le passage par registre. Peut-être que ca a été rajouté depuis.

Les programmes, eux, ne peuvent tourner que sur un système très spécifique qui est une TI-68K avec AMS... Donc faire passer un programme d'un compilateur à un autre me paraît un peu dérisoire...
Si tu ne veux pas profiter des extensions les plus puissantes de GCC, tant pis pour toi. Ce que je sais, c'est que beaucoup de programmes qui se compilent actuellement parfaitement avec TIGCC ne passeront pas ou très mal avec GTC. Je n'appelle pas ça un excellent compilateur, désolé.

Ce que je veux dire c'est que je vais pas me donner la peine d'apprendre toute les extention de GCC dont on se passe très bien sur les autres compilateurs. C'est vrai que je me sert de certaines qui sont toutes simple et pratique mais je suppose que celles là seront dans GTC.
Les programme qui ne passeront pas seront corrigé en quelque minutes a première vue!

Je pense que peu de monde a prévu que quelques personnes pourrait utiliser un truc aussi puissant sur un hardware aussi faible !

A l'époque ou GCC a été créé le P133 c'était une machine de rêve!

Pollux bosse dessus depuis 3 ans, il mérite des encouragements, sont courage est admirable, le résultat encore plus. Vous savez au moins de quoi il est partit précisément ? Ce n'est pas du rejet qu'il mérite !

Certes GTC s'est du boulot est c'est pas normal d'essayer de le descendre comme ca! Le seul truc que l'on peut vraiment lui reprocher c'est que c'est loin Noël!

Uther Lightbringer
a écrit : Génial! Il me manque plus que tu m'annonce un version Linux et je suis comblé. C'est bizarre il me semblait que PpHd avais dit que GTC ne supportait pas le passage par registre. Peut-être que ca a été rajouté depuis.

Il parlait du passage par registres automatique, par un simple switch de compilation.

Ce que je veux dire c'est que je vais pas me donner la peine d'apprendre toute les extention de GCC dont on se passe très bien sur les autres compilateurs. C'est vrai que je me sert de certaines qui sont toutes simple et pratique mais je suppose que celles là seront dans GTC. Les programme qui ne passeront pas seront corrigé en quelque minutes a première vue!

Faux, les extensions les plus dures à implémenter sont aussi (en général) celles qui donnent le code le plus dur à convertir en autre chose (et ce sont donc aussi les extensions les plus utiles).

A l'époque ou GCC a été créé le P133 c'était une machine de rêve!

XDanger parlait des TI-89/92+/V200 comme "matériel faible", pas des P133.

Sur un P133, GCC tourne, et c'est la seule chose qui compte. On s'en fiche du temps de compilation tant qu'il ne fait que quelques secondes. Je faisais tourner TIGCC sur un P120 il n'y a pas trop longtemps, et je ne me suis jamais plaint.

Certes GTC s'est du boulot est c'est pas normal d'essayer de le descendre comme ca! Le seul truc que l'on peut vraiment lui reprocher c'est que c'est loin Noël!

En effet. Je n'aime pas les projets qui sont annoncés "à la fanfare" alors que rien n'est sorti, et c'est aussi une des raisons pour lesquelles je ne vois pas GTC de très bon œil.

Et au fait: je n'aime pas trop le nom "GTC", il est trop proche de "GCC"...

Kevin Kofler
a écrit : Et au fait: je n'aime pas trop le nom "GTC", il est trop proche de "GCC"...

Et moi j'aime pas GCC, c'est trop proche de LCC

GCC est sorti avant.

Il parlait du passage par registres automatique, par un simple switch de compilation.

ok

Faux, les extensions les plus dures à implémenter sont aussi (en général) celles qui donnent le code le plus dur à convertir en autre chose (et ce sont donc aussi les extensions les plus utiles).

Pas pour moi puise que je m'en sert jamais

Sur un P133, GCC tourne, et c'est la seule chose qui compte. On s'en fiche du temps de compilation tant qu'il ne fait que quelques secondes. Je faisais tourner TIGCC sur un P120 il n'y a pas trop longtemps, et je ne me suis jamais plaint.

je n'ai pas dit qu'il ne tourait pas, j'ai dis qu'il était plus lent que CC qui lui tourne sur un 10/12Mhz ca donne une idée de la lourdeur de la bête par rapport a GTC qui pourra tourner directement sur calculette.

En effet. Je n'aime pas les projets qui sont annoncés "à la fanfare" alors que rien n'est sorti, et c'est aussi une des raisons pour lesquelles je ne vois pas GTC de très bon œil.

Et au fait: je n'aime pas trop le nom "GTC", il est trop proche de "GCC"...

La t'abuse quand même! et GCC c'est trop proche de CC

l'inverse Uther, CC est proche de GCC !

si je ne m'abuse CC(le compilateur UNIX) est antérieur a GCC.

je croyais que non ...

lol, Kevin fait des histoire pour les noms

Allez, j'appelle mon prochain jeu de shoot em up Backgamon !

ué ou TI-Chess'mup

> ON PEUT PASSER LES PARAMETRES PAR REGISTRES avec GTC !
ET BIEN IL FAUT DIRE QUE GTC PERMET UNE TELLE EXTENSION, CA EVITERA DES CRITIQUES ! Vous ne participez pas à la discussion, vous ne donnez pas les infos, et après vous *enguirlandez* les autres...

> Les inline ont été supprimés pour les deux compilateurs ! Pour pouvoir comparer, il faut que ça soit comparable
Je sais que inline a été supprimé, c'est marqué plus haut. Mais je l'avais oublié, tu as raison. Donc j'ai dit une bêtise, je le reconnais.

> Si je réagissais comme vous face au Shl d'Orion, vous comprendriez sûrement comment vous êtes ..........
Nous, nous n'avons pas posté de bench biaisé contre shL, ni contre GTC...

> GTC est un très bon compilateur, rapide, produisant du code efficace, oncalc, supportant énormément de choses. Sauf pour quelques syntaxes relevant du standard C99, il peut tout compiler.
Du code efficace ? Tu appelles du code efficace un truc plus de 10% plus lent (pour moins de 5% plus petit) que GCC que tu critiques tant ?

> En effet. Je n'aime pas les projets qui sont annoncés "à la fanfare" alors que rien n'est sorti, et c'est aussi une des raisons pour lesquelles je ne vois pas GTC
de très bon œil.
Oui. Pollux est coutumier de ce genre de trucs, il l'a fait avec GTools, Formula Zero, Bomberman... cf ce que j'ai dit sur le forum Projets.

XDanger a écrit :
> Si je réagissais comme vous face au Shl d'Orion, vous comprendriez sûrement comment vous êtes .......... Nous, nous n'avons pas posté de bench biaisé contre shL, ni contre GTC...

En effet. Et Thibaut, par contre, a posté un bench que je suspecte être biaisé contre TIGCC...

GTC produit du bon code, et il fonctionne on-calc ?
OU EST LE PROBLEME ?

c pas GTC qui a produit le code

Personnellement, je n'appelle pas du bon code un code qui est 5% moins gros, mais plus de 10% plus lent...

Et je viens de voir que je me suis planté dans mon post précédent: Thibaut n'a pas posté un bench biaisé contre GTC, mais pour GTC, ou encore contre TIGCC...

> Nous, nous n'avons pas posté de bench biaisé contre shL, ni contre GTC...

Moi non plus. Comme le dit le tableau, j'ai compilé la même source avec les deux compilateurs, et j'ai comparé le temps de calcul du premier coup par l'IA, sous VTI à vitesse fixe. La différence est de 10 %.

Pour un compilateur si rapide et demandant si peu de mémoire, le résulat est remarquable ! càd que GTC est un bon compilateur : il arrive à qqch de très correct avec peu de moyens et peu de temps.

GCC, qui est un compilateur PC, pourrait faire mieux tout en étant plus rapide. Désolé.


> Thibaut n'a pas posté un bench biaisé contre GTC, mais pour GTC, ou encore contre TIGCC...
Mais oui mais oui


> ET BIEN IL FAUT DIRE QUE GTC PERMET UNE TELLE EXTENSION, CA EVITERA DES CRITIQUES !
Si Kevin et toi avaient été un peu plus lucides (moins concentrés sur votre agressivité envers ce que vous prenez pour un concurrent), vous auriez d'abord attendu que je réponde avant d'embarquer votre gueulante dans des pures suppositions


PpHd > GTC produit du bon code, et il fonctionne on-calc ? OU EST LE PROBLEME ?
Dans l'imagination de l'équipe de TIGCC.

Thibaut a écrit :
> Nous, nous n'avons pas posté de bench biaisé contre shL, ni contre GTC...

Moi non plus. Comme le dit le tableau, j'ai compilé la même source avec les deux compilateurs, et j'ai comparé le temps de calcul du premier coup par l'IA, sous VTI à vitesse fixe. La différence est de 10 %.
Pour un compilateur si rapide et demandant si peu de mémoire, le résulat est remarquable ! càd que GTC est un bon compilateur : il arrive à qqch de très correct avec peu de moyens et peu de temps.

Mais ça reste loin de ce que donne TIGCC en vitesse.
Et pour la taille, TIGCC permet de réduire la taille du code plus que ne le permet GTC, avec des options de style ROM_CALLs par ligne F, passage par registres automatique (avec utilisation de tous les registres, pas seulement ceux détruits par l'appel de fonction comme pour GTC - à moins que Pollux n'ait amélioré cela depuis la dernière fois que le sujet est tombé), ...

GCC, qui est un compilateur PC, pourrait faire mieux tout en étant plus rapide. Désolé.

GTC.exe est aussi un compilateur PC. Et je ne vois pas pourquoi tu attends de GCC d'être plus rapide que GTC sur la même plateforme. GCC est meilleur, donc c'est normal qu'il prenne un peu plus de temps pour compiler.

PpHd
> GTC produit du bon code, et il fonctionne on-calc ? OU EST LE PROBLEME ? Dans l'imagination de l'équipe de TIGCC.

Le problème n'est pas dans notre imagination, le problème est que tu as quelque chose contre TIGCC et que tu essayes donc de détruire notre effort en faisant de la propagande pour faire croire aux gens que GTC serait un remplacement à 100% de TIGCC, alors que c'est très loin d'être le cas.

[/cite]Mais ça reste loin de ce que donne TIGCC en vitesse.
Et pour la taille, TIGCC permet de réduire la taille du code plus que ne le permet GTC, avec des options de style ROM_CALLs par ligne F, passage par registres automatique (avec utilisation de tous les registres, pas seulement ceux détruits par l'appel de fonction comme pour GTC - à moins que Pollux n'ait amélioré cela depuis la dernière fois que le sujet est tombé), ...[/cite]

GTC.exe est aussi un compilateur PC. Et je ne vois pas pourquoi tu attends de GCC d'être plus rapide que GTC sur la même plateforme. GCC est meilleur, donc c'est normal qu'il prenne un peu plus de temps pour compiler.

t'est vraiment obstiné. GTC on-calc et GTC.exe sont presque identique ce qui est un atout majeur(désolé tu va pas aimer). Entre CC et TI-GCC c'est galère.

GTC produit du bon code, et il fonctionne on-calc ? OU EST LE PROBLEME ? >Le problème n'est pas dans notre imagination, le problème est que tu as quelque chose contre TIGCC et que tu essayes donc de détruire notre effort en faisant de la propagande pour faire croire aux gens que GTC serait un remplacement à 100% de TIGCC, alors que c'est très loin d'être le cas.

Le problème c'est que TI-GCC a de la concurence et qu'ils ne supportent pas ca.

t'est vraiment obstiné. GTC on-calc et GTC.exe sont presque identique ce qui est un atout majeur(désolé tu va pas aimer). Entre CC et TI-GCC c'est galère.

Techniquement, ce que tu dis est une énorme connerie (hardware et software très différent...). Mais, qu'est-ce que ça peut nous faire que le source soit sensiblement le même pour les versions on-calc et on-PC, à part savoir que GTC on-calc aura les mêmes défauts que GTC on-PC (à savoir, entre autres, l'absence de certaines des plus puissantes extensions du GNU C, ce qui est un comble pour un truc qui veut dominer TIGCC...) ?

Si Kevin et toi avaient été un peu plus lucides (moins concentrés sur votre agressivité envers ce que vous prenez pour un concurrent), vous auriez d'abord attendu que je réponde avant d'embarquer votre gueulante dans des pures suppositions

Si quelqu'un qui sache quelque chose à propos de GTC (Pollux ou toi...) venait plus souvent sur ce forum pendant la semaine, ou si vous aviez informé Kevin avec des informations récentes, nous n'aurions pas dit cela...

Mais oui mais oui

Et c'est moi, peut-être, qui ai dit une énormité telle que "Kevin défend le kernel" ? Ca arrive à tout le monde de faire des erreurs...
Mais je pense que le fond de ton message n'est pas là... Je trouve (mais il se pourrait peut être que je me trompe ) que la façon dont tu as présenté GTC, est la même que celle dont tu as présenté Einstein (cf ce que j'ai dit sur TI-fr dans le sujet qui est consacré à Einstein)... Pour être plus explicite: tu es insupportable dès que tu parles d'un projet dans lesquels tu es impliqué, ou auxquel tu crois. Kevin et moi le faisons peut-être, mais nous n'avons jamais dit certaines choses que tu as dites. Montre-moi où nous avons posté un bench biaisé, parlé d'un de nos projets de la façon "Un [shell] comme vous n'en avez jamais vu sur TI-68k". Pourtant, sans le boulot de la TIGCC Team, tu aurais eu bien plus de mal à programmer un truc convenable pour les TI-68k... Le premier compilateur C, autre que TIGCC, utilisable, pour TI-68k, arrive seulement maintenant; TIGCC existe depuis bientôt trois ans, ce qui est beaucoup à l'échelle de temps de la communauté TI-68k.

Je reprécise que je ne suis pas membre de la TIGCC Team, et que la TIGCC Team et TICT NE SONT PAS complètement une seule et même équipe (je ne suis pas membre le l'équipe de TIGCC), comme certains imbéciles (qui ont apparemment quitté ce forum, ça fait des vacances !) le disent, et cela même si nous partageons le même forum.

Techniquement, ce que tu dis est une énorme connerie (hardware et software très différent...). Mais, qu'est-ce que ça peut nous faire que le source soit sensiblement le même pour les versions on-calc et on-PC, à part savoir que GTC on-calc aura les mêmes défauts que GTC on-PC (à savoir, entre autres, l'absence de certaines des plus puissantes extensions du GNU C, ce qui est un comble pour un truc qui veut dominer TIGCC...) ?

Tu fait exprès de pas comprendre!! C'est le comble de la mauvaise fois la! Bien sur que le fichier GTC.EXE et GTC(sur TI) seront différents vu qu'il ne tourneront sur le même processeur. Mais il auront été compilés acec un source C proche et donc tout ce qui sera compilé sur PC le sera aussi sur calculette de la même manière : on pourra donc enfin passer son code de PC sur calculette sans se poser de questions.
Et pour les extention GNU j'en ai rien a foutre, ca serait du K&R que ca m'intéresserait quand même alors les extensions dont la grande majorité des programmeurs C n'a pas connaissance on s'en fiche.

Si quelqu'un qui sache quelque chose à propos de GTC (Pollux ou toi...) venait plus souvent sur ce forum pendant la semaine, ou si vous aviez informé Kevin avec des informations récentes, nous n'aurions pas dit cela...

T'abuse Pollux et Thibaut on pas forcément l'obligation de ce mettre a votre disposition en permanence! et puis quand on ne sait pas on utilise le conditionel ou des formule hypothétiques pour éviter le malentendu.

un truc qui veut dominer TIGCC...

Toujours ce problème de domination. Cette ambience m'enerve de plus en plus. toujours vouloir dominer. Moi je préfere choisir en comparant ce qui et bien et mauvais dans un prog et pas parcequ'on me dit que c'est le meilleur. TIGCC a encore des avantage et GTC a les siens alors arrêtez de parler de domination ca m'énerve vraiment quand je vois les super choses que la communauté peut faire quand elle ne pense pas son temps a s'engueuler.

Tu fait exprès de pas comprendre!! C'est le comble de la mauvaise fois la!

Tu crois vraiment que je n'ai pas compris ? J'ai très bien compris ce que tu voulais dire ! Mais il est évident que je ne peux pas te reprocher d'avoir reformulé ce que tu voulais dire de façon encore plus claire: "Mais il auront été compilés acec un source C proche et donc tout ce qui sera compilé sur PC le sera aussi sur calculette de la même manière : on pourra donc enfin passer son code de PC sur calculette sans se poser de questions."

Et pour les extention GNU j'en ai rien a foutre, ca serait du K&R que ca m'intéresserait quand même alors les extensions dont la grande majorité des programmeurs C n'a pas connaissance on s'en fiche.

Pour les programmeurs C pur qui font de petits programmes C sans se soucier de la vitesse et de la taille, ça va.
Un grand nombre de ces programmeurs-là sont d'ailleurs parmi les newbies... Je précise que je ne suis pas anti-newbie, je constate juste qu'en général, les ewbies commencent des trucs pas trop gros, et essaient de les faire marcher, avant d'optimiser...

Mais pour des programmeurs qui veulent faire des programmes plus gros, en se souciant de la vitesse et de la taille (c'est mon cas pour tthdex; mais je ne me considère pas comme un grand programmeur, je l'ai déjà dit et je le répète pour que Thibaut ne dise pas encore des conneries à propos de cela...), ça peut être important. J'utilise l'ASM inline avec opérandes C, les nested functions... Toutes les optimisations que j'ai faites (et encore, je n'utilise pas le passage de paramètres par registres...) m'ont permis de gagner au moins 15% sur la taille, et beaucoup en vitesse sur le code qui repère les différents types de handles (certes, ça n'est pas le plus long).

T'abuse Pollux et Thibaut on pas forcément l'obligation de ce mettre a votre disposition en permanence! et puis quand on ne sait pas on utilise le conditionel ou des formule hypothétiques pour éviter le malentendu.

Evidemment. Là je ne peux rien te dire. Je me suis mis à critiquer un peu vite, on est d'accord. Mais il ne me paraissait pas évident que GTC supporte le passage de paramètres par registre, alors que le mot-clé inline (que personnellement j'utilise beaucoup plus) ne faisait pas partie de ce qu'il comprenait...
Pour l'usage du conditionnel ou des formules hypothétiques: ça ne s'applique pas qu'à Kevin et moi...


(Le dernier et seul post auquel je réponds ici, est le post n°116).

C'est bizarre, on va enfin avoir un compilateur C on-calc assez puissant qui va pouvoir compiler la plupart des sources pour TIGCC sans trop de modifications, et qui ne va PAS faire de l'ombre tout de suite à TIGCC, je vois pas comment on peut se plaindre et créer autant d'embrouilles en si peu de pages.

Et je me rappelle pas avoir entendu Pollux parler de la sortie de son Bomberman ou de Formula-0, on ne peux pas lui en vouloir de ne pas les avoir sortis.

XDanger : les fonctions imbriquées font gagner de la place ?


> Pour être plus explicite: tu es insupportable dès que tu parles d'un projet dans lesquels tu es impliqué, ou auxquel tu crois.

Je pense que je suis inssuportable surtout pour toi, qui ne supporte personne (à part ceux qui pensent comme toi -Kevin, ...- c'est bien triste).


> Montre-moi où nous avons posté un bench biaisé

Montre-moi où j'ai biaisé mon test de GTC vs GCC.


> parlé d'un de nos projets de la façon "Un [shell] comme vous n'en avez jamais vu sur TI-68k"

Tu as déjà vu un explorateur "à la Window$" sur TI89, distribué publiquement, avant Einstein ?


Kevin > le problème est que tu as quelque chose contre TIGCC et que tu essayes donc de détruire notre effort en faisant de la propagande

Ca me rappelle notre cher Le Pen qui ne trouvait rien d'autre à dire que les résultats du 2nd tour n'étaient que le résultat d'une conspiration des autres partits
N'importe quoi ! Mais où tu vas chercher ça

Je dis que GCC pour 68k génère parfois des horreurs.
J'ai dit méchamment une fois que votre lib était peu optimisée.
Ca signifie que je souhaite la mort de TIGCC, que je veux votre perte ?