GTC : un TIGCC sur votre calculatrice ? - Page 7

Bof c'est inutile de comparer avec et sans "F-line" à mon avis. Ca n'a pas de rapport avec les performances du compilateur.

> En effet, GTC est presque fini
Il est fini C'est l'IDE qui n'est pas terminé, mais on peut compiler sans.

Uther Lightbringer
a écrit : Je ne connais pas grand monde qui connaisse et utilise ces option de la ligne mais c'est vrai que je ne suis pas a moi tout seul représentatif de toute la comunauté.

Ca peux faire gagner pourtant beaucoup de mémoire. Faites de la pub.
ID utilise tout (sauf l'émulator, pas besoin sur >AMS 2.07).

Ca m'intéresse, si ça peut réduire la taille d'Einstein !!

Mais je n'aime pas faire sans comprendre... A quoi sert chacune des options ?

Je te dis cependant que je n'avais qu'assez modérément apprécié que tu sembles t'étonner que j'aie dit que je n'était pas un expert de tous les sujets en programmation (il n'y a aucun sujet où je sois un expert en programmation, d'ailleurs)...

Mon post #163 vise surtout Kevin qui semble prendre plaisir à cracher sur un des plus gros projets jamais effectués sur Ti, et également l'un des plus ambicieux, simplement parcequ'il y voit la concurence.

OK, je me suis énervé. Je te présente mes excuses pour cela.

Ok sans rancune

Thibaut > C'est expliqué dans la doc :
http://tigcc.ticalc.org/doc/gnuexts.html
http://tigcc.ticalc.org/doc/comopts.html
http://tigcc.ticalc.org/doc/httigcc.html

Il y a à peu près tout là dedans...

tanquiou

pour mes programmes, j'utilise pas mal d'options aussi... histoire d'optimiser...
les rom_calls en 1111 (sans installer d'émulateur qd je prog pr moi et moi seul, vu que j'ai une rom2.05 qui a le 1111 par défaut, et que, de toute façon, preOS le fait aussi)
-fomit-frame-pointer vu que je fais pas vraiment de flottants qd je prog
et suppression des détection de calc, de rom ou autre (du moins, qd je code pr moi et moi seul : pas besoin de bouffer de la mem pr rien, alors que je prog spécifiquement pr MA ti )

Bon je vais répondre à quelques questions (je remercie au passage ceux qui ont répondu à ma place, je ne suis pas rentré chez moi depuis la Toussaint) :

- Pas de passage d'argument par registre
si, cf plus haut
- Pas de version Linux(a ce que je sache)
non, mais GTC n'est pas principalement un compilo on-PC (voilà qui va rassurer Kevin )


XDanger :
- les cast constructors/compound literals (très pratique et gagne du temps et de la place si les paramètres sont constants)
implémenté
- 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...)
aucun intérêt : le code généré n'est vraiment moins efficace ;
+ il force le compilo à générer des frame pointers
+ il ne met pas les variables utilisées dans des sous-fonctions dans des registres
+ en passant un pointeur de structure tu peux avoir exactement le même résultat tout en étant bcp plus propre, plus portable et en générant du code plus efficace.
- 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 seul truc qui manque à la version actuelle...
- le keyword inline (ça peut améliorer la vitesse, *légèrement*)
intérêt limité, et ça ralentirait singulièrement le compilo (et la mémoire requise augmenterait)
- les attributs de fonctions ou de variables ( __attribute__((__stkparm__)) ou __regparm__(n), et plein d'autres attributs...)
implémenté (et même __regparm__(n_dregs,n_aregs), contrairement à TI-GCC)
- 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 ?)
implémenté
- conditionals with omitted operands (pratique, même si ça n'est pas indispensable)
implémenté
- les types 'enum' incomplets (une bonne partie de TIGCCLIB est basée là-dessus...)
je pense que c'est implémenté puisque TI-GCC Lib marche


> Il parlait du passage par registres automatique, par un simple switch de compilation.
ça existe aussi

> 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 ?

Tu ne te rends pas compte de l'énormité de ce que tu dis C'est vraiment négligeable devant le fait d'être on-calc et d'avoir une compilation immédiate...

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.

Exactement, GTC version PC n'est pas censé remplacer définitivement TI-GCC, il permet simplement de porter les progs plus simplement pour GTC on-calc, ou tout simplement de recompiler sur PC les programmes faits on-calc avec GTC.

Solution: tu compiles ta source en -O0 tant que tu ne la distribues pas, ça va plus vite. Tu peux aussi recompiler GCC en -O3 au lieu de -Os si ça te chante.

Problème : la taille a vite fait d'être multipliée par 2, donc c pas terrible pour un prog de 40 ko...

Bon, vu que la liste d'extensions donnée par XDanger était incomplète, voilà une liste complète:
Statements and Declarations in Expressions
Locally Declared Labels
Labels as Values
Nested Functions
Constructing Function Calls
Naming an Expression's Type
Referring to a Type with 'typeof'
Generalized Lvalues
Conditionals with Omitted Operands
Double-Word Integers
Complex Numbers
Hex Floats
Arrays of Length Zero
Arrays of Variable Length
Macros with a Variable Number of Arguments
Non-Lvalue Arrays May Have Subscripts
Arithmetic on void and Function Pointers
Non-Constant Initializers
Compound Literals (Cast Constructors)
Designated Initializers
Cast to a Union Type
Case Ranges
Specifying Attributes of Functions
Specifying Attributes of Variables
Specifying Attributes of Types
Attribute Syntax
Prototypes and Old-Style Function Definitions
C++ Style Comments
Dollar Signs in Identifier Names
Escape Character in Constants
Inquiring on Alignment of Types or Variables
Inline Functions
Inline Assembler
Controlling Names Used in Assembler Code
Variables in Specified Registers
Alternate Keywords
Incomplete 'enum' Types
Function Names as Strings
Getting the Return or Frame Address of a Function
Other built-in functions provided by GCC
Slightly Looser Rules for Escaped Newlines
String Literals with Embedded Newlines
Mixed Declarations and Code
Unnamed struct/union Fields within structs/unions
Binary Numbers
Definite Access of Volatile Objects

Et je rajoute une liste incomplète de nouveautés du C99 qui sont permises par TIGCC avec -std=gnu99:
- boucles for(int i=0;i<10;i++) (Backgammon les utilise par exemple.)
- type _Bool natif
...

Et pour le passage par registres, GTC a toujours la restriction qu'on ne peut utiliser que d0-d2/a0-a1? Dans ce cas, l'intérêt serait très limité. Et ça voudrait aussi dire que GTC ne sera pas compatible avec les prochaînes versions de TIGCCLIB parce que mon __(v)cbscanf utilise des arguments passés en a2, a3 et a6 (en plus de a0 et a1).

Pour la liste complète des extensions, bcp sont totalement inutiles...

Et je rajoute une liste incomplète de nouveautés du C99 qui sont permises par TIGCC avec -std=gnu99:
> - boucles for(int i=0;i<10;i++) (Backgammon les utilise par exemple.)
il me semble que ça marche (les déclarations en milieu de programme type C++ sont aussi autorisées)

> - type _Bool natif
enum { false, true };
c'est assez compliqué à rajouter dans un prog

> ...
détaille un peu

La différence, c'est qu'avec du _Bool natif, tu peux être sûr que ta variable vaut toujours 0 et 1. Donc plus besoin de mettre des !! de partout.

??? tu veux dire que ça rajoute simplement (_Bool)x = !!x ? c'est nul...

Sinon c quoi les autres extensions du C-99 qui sont si primordiales?

T'es lourd Kevin.
Fout la paix à Pollux, franchement la majorité des programmeurs n'en à rien à foutre de la plupart de ces extensions. Elles ne sont pas du tout indispensables pour programmer en C. Je ne comprend pas que tu ne puisses pas accepter que GTC est un programmme assez révolutionnaire pour nos TIs, qu'il ne mérite qu'à être applaudit et encouragé (encouragements pour s'améliorer, par exemple....).

Va chanter sur tous les toits que GTC est une merde, on sait que tu en as très envie, que ton instinct de chef dominateur t'y pousse. Mais tu es ridicule je crois bien, à démonter un tel programme que tu seras le seul à rejeter.

-----------
C'était ma petite gueulante

Franchement j'ai commencé a lire la doc des extension tant kevin insistant sur leur importance : je me suis arrété avant le tiers tant je trouvais la majorité inutile, parfois déroutant par rapport aux standards C et que ca donnait souvent des trucs pas clairs. Certaines sont vraiment utiles mais ces extensions sont celles qui seront implémentées dans GTC.
Il faudra m'indiquer l'interet du bool en C : le C est un langague qui n'est pas cencé macher le travail du programmeur sinon on prend du Basic. Si ca continue bientot on va voir TI-GCC faire les passages de paramètres par adresse implicitement.
Alors Kevin, arrete d'essayer d'enfoncer GTC c'est vraiment très bas de ta part.
------------
sinon revenons au vraies questions maintenant que revoila Pollux:
Est-ce que GTC sortira dans les délais impartis?
Est-ce que GT-Basic sera aussi Relaesé?
Sinon quand?

Vi GT-Basic, c le plus important dans l'histoir, là

Pollux
a écrit : Sinon c quoi les autres extensions du C-99 qui sont si primordiales?

La plupart des nouveautés du C99 sont aussi des extensions GNU par rapport au C90, donc ils sont déjà dans la liste des extensions GNU.

Thibaut a écrit :
T'es lourd Kevin.
Fout la paix à Pollux, franchement la majorité des programmeurs n'en à rien à foutre de la plupart de ces extensions. Elles ne sont pas du tout indispensables pour programmer en C. Je ne comprend pas que tu ne puisses pas accepter que GTC est un programmme assez révolutionnaire pour nos TIs, qu'il ne mérite qu'à être applaudit et encouragé (encouragements pour s'améliorer, par exemple....).

Le jour où vous (surtout toi) arrêterez de comparer GTC à TIGCC (cf. le titre de ce topic), j'arrêterai moi aussi.
Je montre seulement que GTC n'est pas du tout équivalent à TIGCC, c'est tout.

Pourquoi ne pas comparer: c'est deux compilateurs C pour TI qui compilent a peut de chose pres le m^eme code.
Il n'est pas équivalent il est bien mieux a mon avis!

Tant qu'on a rien on ne peut pas juger... Alors pour dire qu'il est bien mieux...

[Les features implémentées dans GTC]
Très bien. Il ne manque plus que l'ASM inline avec opérandes C, qui est vraiment puissant. Mais ce que tu as fait est déjà de l'excellent travail.
Le fait que regparm soit implémenté avec la séparation registres de donnée / registres d'adresse (ce qui est intéressant en soi), rend TIGCC et GTC incompatibles sur ce point. Ca n'est cependant pas rédhibitoire.

> Tu ne te rends pas compte de l'énormité de ce que tu dis. C'est vraiment négligeable devant le fait d'être on-calc et d'avoir une compilation immédiate...
Tu as raison. J'ai dit une bêtise. Personnellement, je ne programme pas on-calc, donc c'est vrai que cet aspect-là m'a peu touché.


>> 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.
> Exactement, GTC version PC n'est pas censé remplacer définitivement TI-GCC, il permet simplement de porter les progs plus simplement pour GTC on-calc, ou tout simplement de recompiler sur PC les programmes faits on-calc avec GTC.
Ce montre que Pollux n'est pas borné. Je ne suis pas sûr qu'il soit possible d'en dire autant de celui qui est visé par ce que dit Kevin (je ne suis pas sûr de son identité, et je n'ai ni le temps ni l'envie de le rechercher, mais je me doute de qui c'est...).

Va chanter sur tous les toits que GTC est une *****, on sait que tu en as très envie, que ton instinct de chef dominateur t'y pousse. Mais tu es ridicule je crois bien, à démonter un tel programme que tu seras le seul à rejeter.

Il y a une différence entre montrer que GTC n'est pas absolument équivalent à TIGCC, et dire que GTC est une sous-***** (ce qui est très loin d'être vrai !) !

Toi, tu es ridicule avec ta thématique selon laquelle Kevin est dominateur.
Si Kevin (et plus généralement la TIGCC Team) était si dominateur/dominatrice que ça, la TIGCC Team:
- n'autoriserait pas qu'on utilise tipatch.lib dans un autre compilateur.
- n'autoriserait pas qu'on utilise tigcc.a dans un autre compilateur.
- n'autoriserait pas qu'on utilise la doc de TIGCC, qui est de loin la plus complète, dans un autre compilateur.
- dénigrerait publiquement lourdement les compilateurs concurrents, ce qui n'est pas du tout le cas.

Quand GTC sera sorti, je m'engage ici devant tous, à ce qu'un post soit fait sur le forum de TIGCC/TICT. Il sera cependant sur le forum off-topic, car c'est un topic qui serait off-topic dans tous les autres forums.

[dernier post lu: le n° 198 de Xeno].

[EDIT: corrigé une faute de frappe.]

Uther Lightbringer
a écrit : Si ca continue bientot on va voir TI-GCC faire les passages de paramètres par adresse implicitement.

Le passage par référence ? C'est quand même super pratique en C++. Moi ça m'amuse pas vraiment de rajouter des & et des * partout. Ca ne me dérangerait pas que ce soit en standard en C.

Uther Lightbringer
a écrit : Pourquoi ne pas comparer: c'est deux compilateurs C pour TI qui compilent a peut de chose pres le m^eme code.

C'est exactement ça qui n'est pas vrai, et c'est ce que certains n'ont pas compris, et c'est ce que je répète sans arrêt. Je ne veux pas "démonter" GTC, je veux juste montrer qu'il ne vaut pas TIGCC!

Pollux n'a même pas voulu reprendre un par un la liste complète des extensions GNU, il les a simplement traîtées de "totalement inutiles", ce qui est son avis personnel, et très loin d'être une position objective.

Il n'est pas équivalent il est bien mieux a mon avis!

Alors là, tu fais exprès de me provoquer.
C'est quoi qui est mieux? La possibilité de programmer on-calc? Je veux voir comment tu veux faire rentrer un programme réel (pas de "Hello, World!") on-calc. Quelques exemples de programmes réels:
- Backgammon: fichier .c de 87494 octets, trop grand pour la calculatrice
- TI-Chess 4.00: 21 fichiers .c et 14 fichiers .h pour un total de 472 KO. Le plus grand fichier .c est engine.c qui fait 105760 octets, ce qui est trop grand pour la calculatrice.
...
Un compilateur on-calc est quelque chose de bien, mais il ne pourra jamais remplacer TIGCC. Quant à la version PC de GTC, je ne vois pas pourquoi on utiliserait un compilateur avec des extensions en moins et presque rien en plus. (Je peux rajouter le __attribute__((regparm(3,2))) (donc à 2 paramètres) à GCC pour TIGCC 0.95. Et il paraît que c'est la seule chose qu'il y a en plus.)

XDanger a écrit :
[Les features implémentées dans GTC] Le fait que regparm soit implémenté avec la séparation registres de donnée / registres d'adresse (ce qui est intéressant en soi), rend TIGCC et GTC incompatibles sur ce point. Ca n'est cependant pas rédhibitoire.

Je vais rajouter ça à TIGCC 0.95. Ça ne devrait pas être trop compliqué, surtout par rapport à tout le reste du travail pour porter le patch TIGCC vers GCC 3.3.

Je ne suis pas sûr qu'il soit possible d'en dire autant de celui qui est visé par ce que dit Kevin (je ne suis pas sûr de son identité, et je n'ai ni le temps ni l'envie de le rechercher, mais je me doute de qui c'est...).

Et tu as raison.

Thibaut a écrit :
[GTC] : un TIGCC sur votre calculatrice ?
Voici un comparatif entre TIGCC et la version PC de GTC.

Voilà.

Pollux
a écrit : C'est vraiment négligeable devant le fait d'être on-calc

Il est vrai que c'est bien d'avoir un compilateur on-calc (et tu avances vraiment la programmation on-calc par rapport à CC). Ceci dit, contrairement à ce que certains ici (et je parle de T... et de U... L... plus que de toi quand je dis ça) ont l'air de penser, la programmation on-calc ne pourra jamais remplacer TIGCC. (Pour le raisonnement me permettant de dire cela, cf. message #281 ci-desus.)

et d'avoir une compilation immédiate...

TIGCC est-il si lent que ça??? Personnellement, je le trouve tellement rapide que je ne compile jamais avec autre chose qu'avec Build (recompiler le projet entier, même si rien n'a changé).
Un exemple: TI-Chess 4.00 est compilé en entier en 118 secondes, alors qu'il y a 8 versions compilées (version TI-89 en 4 langues et version TI-92+ en 4 langues). Ça ne fait même pas 15 secondes par version. Franchement, ce n'est pas beaucoup.
Et la raison pour laquelle GCC est moins rapide que GTC est le nombre d'optimisations apportées à la source compilée.

Et au fait: TIGCC 0.95 permettra probablement de programmer en Objective-C et peut-être aussi en C++. (Il y a un certain Stéphane Akhoun qui travaille là-dessus.) Je veux voir GTC permettre cela.

disons que GTC ne peux pas se permettre de prendre la même place que TIGCC...

la programmation on-calc ne pourra jamais remplacer TIGCC

je suis assez d'accord.
du moins, pr les gros projets
(ou, en fait, pr n'importe quel projet une fois qu'on a un certain niveau de prog)

qd on débutte, c bien pratique, surtout vu qu'on écrit que de petits progs
(là, je parle pr l'ASM... mais ça doit être pareil pr le C)


question vitesse de TIGCC, ça dépend aussi du système d'exploitation utilisé
sous 98se, il me fallait 1min30 environ pr compiler Krypton...
je suis passé à bcp moins de temps (je sais plus exactement, mais pas plus de 30 secondes) sous XP.
(avec la même version de TIGCC)

Le temps que j'ai cité pour TI-Chess, c'était sous Windows Me.

je précise que je n'ai rien changé au niveau matériel sur le PC entre les deux tests.
et que XP était alors configuré avec les réglages par défaut (ct le tout début que e l'avait)

heu... en fait, je pense que ce qui faisait ramer était l'IDE...
(en compilant avec des fichiers .bat sous 98, ça ramait moins que en compilant depuis l'IDE)
(arf... si je m'en était souvenu plus tot, j'aurai pas posté plus haut )

C'est exactement ça qui n'est pas vrai, et c'est ce que certains n'ont pas compris, et c'est ce que je répète sans arrêt. Je ne veux pas "démonter" GTC, je veux juste montrer qu'il ne vaut pas TIGCC!

Il n'est pas absolument équivalent à TIGCC mais il en est très proche en ce qui concerne le C standard et les extensions utiles(je parle pour mon cas, car il est vrai que les opinions peuvent diverger sur ce qu'est une extention utile).

Pollux n'a même pas voulu reprendre un par un la liste complète des extensions GNU, il les a simplement traîtées de "totalement inutiles", ce qui est son avis personnel, et très loin d'être une position objective.

En tout cas je partage l'avis de Pollux. Elles peuvent peut-etre servir parfois mais on peut toujours s'en passer.
Je suis pret a parier que 90% de programmeur C ne connaissent pas ces extentions(a part celle tirées du C++ qu'ils peuvent utiliser sans s'en rendre compte) et que donc par conséquent très peu de gens utiliseront.

Alors là, tu fais exprès de me provoquer.
C'est quoi qui est mieux? La possibilité de programmer on-calc? Je veux voir comment tu veux faire rentrer un programme réel (pas de "Hello, World!") on-calc. Quelques exemples de programmes réels:
- Backgammon: fichier .c de 87494 octets, trop grand pour la calculatrice
- TI-Chess 4.00: 21 fichiers .c et 14 fichiers .h pour un total de 472 KO. Le plus grand fichier .c est engine.c qui fait 105760 octets, ce qui est trop grand pour la calculatrice. ...

Oui mais ces fichiers n'on pas été prévus pour la prog on-calc et je suis sur que si on le voulait on pourait facilement réduire leur taille à - de 64Ko ou les séparer en plusieurs parties : du moins pour Backgammon, pour TI-Chess ca devrait etre plus dur.
C'est la tout l'interet de GTC pouvoir programmer on-calc tout en ayant l'assurance de pouvoir continuer ON-PC sans se prendre la tete. C'set vrai que la prog On-calc a des limites, je ne vais pas le nier mais de la a la jetter a la poubelle, c'est exagéré.

Un compilateur on-calc est quelque chose de bien, mais il ne pourra jamais remplacer TIGCC. Quant à la version PC de GTC, je ne vois pas pourquoi on utiliserait un compilateur avec des extensions en moins et presque rien en plus. (Je peux rajouter le __attribute__((regparm(3,2))) (donc à 2 paramètres) à GCC pour TIGCC 0.95. Et il paraît que c'est la seule chose qu'il y a en plus.)

L'interet de la version PC de GTC est:
- que l'on pourra récuppérer le code on-calc sur PC sans difficulté
- que ca devrait etre plus rapide que TIGCC qui met au minimum 30 secondes pour compiler mes projets les plus simples(et encore j'ai abandonné l'IDE) bon je sais pouse n'est pas un argument très important pour la pluspart des programeur qui tournent avec des PC de 2Ghz mais je dois me contenter d'un 133 en ce moment

Et au fait: TIGCC 0.95 permettra probablement de programmer en Objective-C et peut-être aussi en C++. (Il y a un certain Stéphane Akhoun qui travaille là-dessus.) Je veux voir GTC permettre cela.

La tu deviens intéréssant!! Si vous arrivez à implémenter cela ca sera un avantage nettement plus conséquent que cette flopée d'extensions inutiles

Tu sous-entends là que TIGCC n'acceptera pas le code accepté par GTC. Ça ne devrait pas être le cas normalement.