GTC : un TIGCC sur votre calculatrice ? - Page 6

Uther Lightbringer : c'est clair. Mais il faut bien que ces messieurs à tendance dominatrice trouvent quelque chose à reprocher à ce qu'ils voient comme leur concurrent
J'aimerais bien les voir programmer un compilateur, tiens.... En constatant la difficulté, tu peux être sûr qu'il la fermeraient un peu plus. Ca n'a absolument rien à voir avec un Backamachin ou un TICTex et ses extensions pour visualiser des handles ou je sais pas quoi !
J'ai pas mis en pause (pour longtemps ) Azur par démotivation... Je ne suis pas le seul à le penser, je l'ai déjà lu plusieurs fois, et je l'ai constaté : la conception d'un compilateur fait partie des projets les plus difficiles en programmation. A côté, un moteur 3D, une IA d'échecs, etc, c'est plus grand chose.

Thibaut
a écrit : J'aimerais bien les voir programmer un compilateur, tiens.... En constatant la difficulté, tu peux être sûr qu'il la fermeraient un peu plus. Ca n'a absolument rien à voir avec un Backamachin ou un TICTex et ses extensions pour visualiser des handles ou je sais pas quoi !

Moi, je "programme" un compilateur exactement comme Pollux: il a pris un compilateur existant et il l'adapte. Je fais la même chose avec GCC... (C'est moi qui m'occupe tout seul de la version TIGCC de GCC depuis un certain temps déjà.)

Thibaut
a écrit : Il est mille fois plus convivial, rapide, performant.

XDanger
a écrit : Rapide et performant, le bench que tu as posté semble le montrer (du moins pour des sources qui ne sont pas trop compliqués...).

Ah, parce que pour vous, un compilateur "performant" est un compilateur qui met peu de temps à compiler une source??? Ce n'est vraiment pas ça qui compte pour la performance du compilateur. Quel intérêt d'avoir sa source compilée en 5 secondes au lieu de 10??? D'ailleurs, TIGCC est compilé en -Os.

Kevin > Quelles sont les sources qu'adapte Pollux ? Malgré un mois de recherche, le seul compilateur C dont le fichier exécutable descend en dessous de 100 ko est Tiny C Compiler.

Il paraît que c'est le même que Ontic, c'est-à-dire celui-là:

/*
 *	68000 C compiler
 *
 *	Copyright 1984, 1985, 1986 Matthew Brandt.
 *  all commercial rights reserved.
 *
 *	This compiler is intended as an instructive tool for personal use. Any
 *	use for profit without the written consent of the author is prohibited.
 *
 *	This compiler may be distributed freely for non-commercial use as long
 *	as this notice stays intact. Please forward any enhancements or questions
 *	to:
 *
 *		Matthew Brandt
 *		Box 920337
 *		Norcross, Ga 30092
 */

De toutes facons, c'est pas la peine de s'engueuler pour ca, vu que ca sortira pas avant 55 ans ...

Durant la phase de développement, je trouve ça très utile d'avoir sa source compilée en 5 sec au lieu de 10. Quand on vient de corriger une ligne et qu'on est impatient de voir si à était le bug, 5 secondes de différence sont énormes.

La compilation en vu de diffuser l'exécutable généré, c'est autre chose...

C'est vrai que c'est bien pratique curtout quand comme moi, on travaille sur une vieille machine

le sage a encore parle.

Blue_Z a écrit :
Durant la phase de développement, je trouve ça très utile d'avoir sa source compilée en 5 sec au lieu de 10. Quand on vient de corriger une ligne et qu'on est impatient de voir si à était le bug, 5 secondes de différence sont énormes.
La compilation en vu de diffuser l'exécutable généré, c'est autre chose...

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.

Et personnellement, je compile mes programmes très fréquemment quand je teste, et le temps de compilation ne m'a jamais gêné. (Au cas où tu ne serais pas au courant, j'ai aussi sorti un jeu en C: Backgammon. Donc je ne parle pas que de temps d'assemblage, mais bien aussi de temps de compilation C.)

Uther Lightbringer
a écrit : Tu oublie:- ceux qui ont appris le C ANSI et n'ont pas envie ou le temps de ce farcir de nombreuses extensions plus ou moins utiles dont on peut se passer.

Oui, je fais partie de ceux-là...
J'aimerais bien connaître toutes ces extensions, mais elles ne sont pas dans mon bouquin
Il faut juste lire ça : http://tigcc.ticalc.org/doc/gnuexts.html ou bien il y en a encore d'autres ?

Ca n'a absolument rien à voir avec un Backamachin ou un TICTex et ses extensions pour visualiser des handles ou je sais pas quoi !

Je ne me souviens pas d'avoir dit que c'était facile/pas difficile de programmer un compilateur, mais bon... Je ne me souviens pas non plus que Kevin l'ait dit.
Nous savons tous parfaitement, qu'écrire un bon compilateur à partir de rien est extrêmement difficile. Ecrire un bon OS en partant de rien, est aussi extrêmement difficile. Le temps mis pour le développement dépend du nombre de personnes, mais ça prend des années si on est tout seul.

A côté, un moteur 3D, une IA d'échecs, etc, c'est plus grand chose.

Je sais bien que je ne suis pas un grand programmeur, mais actuellement, je ne sais pas par quel bout prendre le problème pour faire à partir de rien, un moteur 3D, ou pire, une IA d'échecs... Je n'ai presque aucune connaissance en algorithmie, et ce n'est pas en classe que je vais devenir compétent en programmation...

tthdex N'EST PAS une extension de tictex pour avoir des infos sur les handles. C'est un programme à part, qui fait partie de la TIGCC Tools Suite. Tu n'es pas toujours très fort pour savoir ce que font les autres; mais tu es parfois très fort pour les critiquer...

Ah, parce que pour vous, un compilateur "performant" est un compilateur qui met peu de temps à compiler une source??? Ce n'est vraiment pas ça qui compte pour la performance du compilateur. Quel intérêt d'avoir sa source compilée en 5 secondes au lieu de 10??? D'ailleurs, TIGCC est compilé en -Os.

Pas pour moi, en tout cas. Je parle de la taille du code généré: GTC semble avoir généré un code 5% plus petit (mais 10% plus lent...).


Blue_Z: 5 secondes d'écart, n'est pas grand chose comparé au temps qu'il fallait dans les années 1980 (1 à plusieurs minutes) pour faire la même chose...


Comme vous l'aurez certaintement constaté, je ne fais pas partie de ceux qui ont appris à fond le C ANSI. Je me suis vraiment mis à la programmation avec TIGCC, pour la TI-89. J'avais fait du C sur PC, mais c'était d'un faible niveau.
Pour programmer sur TI-89/92+/V200, j'aurais du mal à me passer de certaines extensions du GNU C...

Kevin > Ah, parce que pour vous, un compilateur "performant" est un compilateur qui met peu de temps à compiler une source???

MMMMMhhh permet-moi de rire :
GTC est 2 fois plus rapide sur un processeur plus de 20 fois plus lent (j'ai un AMD K6 à 225 MHz).
Autrement dit, il est à peu près 40 fois plus rapide que TIGCC, pour un code très bon (il optimise très bien, GTC ! mais pas encore aussi bien que GCC).
Je doute franchement qu'il faille 40 fois plus de temps pour ne gagner que 10% en vitesse.


> Moi, je "programme" un compilateur exactement comme Pollux

Là je ne vais pas me permettre de rire car je ne sais pas du tout ce que tu fais exactement.
Pollux a réellement programmé GTC. 20.000 lignes de son code source ont été tapées de sa main. Je ne crois pas que tu en ais fait autant sur GCC.
N'oublie pas que Pollux a dû ajouter et donc programmer totalement, sur ces 20.000 lignes :
- un préprocesseur entrelacé à l'analyse lexicale (morceau énorme),
- les déclarations ANSI et toute la syntaxe qui va avec (très gros morceau aussi),
- le support des librairies statiques,
- beaucoup de bugs en moins,
- un assemblage intégré (morceau énorme !), rappelons que GTC ne sort pas un .asm mais un .exe,
- pff j'en oublie, il faudrait lui demander directement.

Ca n'a plus rien à voir avec C68k. Il a réalisé un boulot titanesque.

Impressionant quand même comment certains rechignent sur un travail aussi énorme.

Comparer GTC et TIGCC est totalement stupide, quelles que soient les performances de l'un ou de l'autre. Je voudrais également savoir si ceux qui critiquent si bien sont sûr avoir les capacités pour faire ne serait-ce que la moitié du travail que semble avoir accompli Pollux ?

Thibaut > un AMD K6 à 225 MHz est bien plus que 20 fois plus rapide qu'une TI-68k cadencée à 10mhz.

sinon le code de GTC fait combien de lignes environ ? 26000 ?

C'est bien pour ça que j'ai dit "sur un processeur plus de 20 fois plus lent "

Vertyos : ce que je lui reproche avant tout, c'est d'enfoncer GTC parcequ'il n'intègre pas encore certaines choses

jackiechan a écrit :
Oui, je fais partie de ceux-là...
J'aimerais bien connaître toutes ces extensions, mais elles ne sont pas dans mon bouquin
Il faut juste lire ça : http://tigcc.ticalc.org/doc/gnuexts.html ou bien il y en a encore d'autres ?

Elles sont toutes dans ce document. Du moins les extensions documentées. Il y a peut-être des extensions non-documentées, mais ce sont des bogues, pas des extensions voulues. Il y avait aussi des extensions non-documentées pour l'usage interne à GCC, mais il me semble qu'elles ont toutes été documentées entretemps.

XDanger
a écrit : Pas pour moi, en tout cas. Je parle de la taille du code généré: GTC semble avoir généré un code 5% plus petit (mais 10% plus lent...).

C'est parce que Thibaut n'a pas utilisé les options d'optimisation de GCC ou de TIGCCLIB:
-fomit-frame-pointer -mregparm=6 -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse
Avec ça, il a vite du code plus petit qu'avec GTC, qui ne permet pas ces options.

Thibaut a écrit :
Kevin > Ah, parce que pour vous, un compilateur "performant" est un compilateur qui met peu de temps à compiler une source???

MMMMMhhh permet-moi de rire :
GTC est 2 fois plus rapide sur un processeur plus de 20 fois plus lent (j'ai un AMD K6 à 225 MHz). Autrement dit, il est à peu près 40 fois plus rapide que TIGCC, pour un code très bon (il optimise très bien, GTC ! mais pas encore aussi bien que GCC).

Arrête de raconter n'importe quoi! La version que tu as utilisée dans les benchmarks est la version PC de GTC, donc on était sur la même plateforme!

Je doute franchement qu'il faille 40 fois plus de temps pour ne gagner que 10% en vitesse.

Et tu as tord de doûter. L'optimisation est une tâche difficile! Et puis il ne faut que 2 fois plus de temps, pas 40, cf. remarque ci-dessus.

Ha ouai il faut que je me réveille moi
Pardon !


> fomit-frame-pointer -mregparm=6 -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse

Arrête de raconter n'importe quoi ! Il faut comparer une génération comparable : les deux doivent avoir les mêmes options pour générer un code comparable.

C'est comme si t'allais peser un vélo et un camion, en attachant des ballons gonflés à l'hélium au camion, pour ensuite prétendre que le camion pèse moins lourd que le vélo

Et après on dit que je fais des tests "biaisés"

Mais non, il faut comparer GTC avec les meilleures options qu'il propose et TIGCC avec les meilleures options qu'il propose. Je ne vois pas pourquoi il faudrait limiter artificiellement TIGCC dans une comparaison. S'il a des options pour optimiser mieux que GTC, ça veut dire qu'il optimise mieux en pratique. En pratique, on utilise les meilleures options, on ne limite pas artificiellement TIGCC.

fomit-frame-pointer -mregparm=6 -DUSE_FLINE_ROM_CALLS -DUSE_INTERNAL_FLINE_EMULATOR -fno-function-cse

Qui dans la pratique utiliserai seulement la moitié de ces paramètres les seul paramètres vraiment utilisés dans la pratique sont -Ox.

Uther Lightbringer
a écrit : Qui dans la pratique utiliserai seulement la moitié de ces paramètres les seul paramètres

Moi...

J'utilise USE_FLINE_ROM_CALLS et USE_FLINE_EMULATOR (et -fno-function-cse, qui est nécessaire pour que ça marche) dans Backgammon. Je n'utilise pas le passage par registre automatique, mais j'ai déclaré chaque fonction en passage par registres manuellement.

à part son super jeu de snake, il a fait quoi Pollux ? (je sous entend projet terminé)

rien: il est un peu comme moi: il commence beaucoup de truc et les fini rarement. Ceci dit avec un projet comme GTC c'est normal qu'il ai du mettre pas mal de chose de coté

GTC est 2 fois plus rapide sur un processeur plus de 20 fois plus lent (j'ai un AMD K6 à 225 MHz).

Joli argument que de comparer deux machines qui ne sont pas comparables: type de processeur différent; tout le reste du hardware différent aussi; software très différent... Surtout que c'est sur la même plateforme que les tests ont été faits (cf post 168, Kevin l'a dit). Mais on arrête là car tu t'es excusé au post 169.

Je voudrais également savoir si ceux qui critiquent si bien sont sûr avoir les capacités pour faire ne serait-ce que la moitié du travail que semble avoir accompli Pollux ?

Tu sais lire ? Regarde le post 161 !


Et je suis un peu d'accord avec Thibaut, un peu d'accord avec Kevin. Je pense qu'il faut faire trois benchs, pas moins, pour diminuer les polémiques: un bench avec les mêmes options de compilation; un bench avec les options qui produisent le code le plus efficace en taille; un bench avec les options qui produisent le code le plus efficace en vitesse.
Il va sans dire que les benchs doivent être 'transparents' (code source du bench et options de compilation, machine sur laquelle on teste... disponibles pour tout le monde). En général, je le fais (cf ce que j'ai fait l'autre fois pour les fonction de dessin de chaîne de caractères).

Qui dans la pratique utiliserai seulement la moitié de ces paramètres les seul paramètres vraiment utilisés dans la pratique sont -Ox.

Ce n'est pas parce que toi, tu sembles ne pas les utiliser, que personne ne les utilise ! Tous mes programmes sont compilés au minimum avec -O2, -fomit-frame-pointer (et -mpcrel si c'est possible, c'est à dire que GCC génère du code correct, ce qui n'est malheureusement pas toujours le cas). Je n'ai encore jamais utilisé les ROM_CALLs par F-Line, mais j'utilise le passage de paramètres par registres, dans la déclaration de la fonction.

rien: il est un peu comme moi: il commence beaucoup de truc et les fini rarement. Ceci dit avec un projet comme GTC c'est normal qu'il ai du mettre pas mal de chose de coté

En effet, c'est normal. Ca fait combien de temps qu'il bosse sur GTC ?
En tout cas, Pollux est connu, et pas seulement sur ce forum, pour commencer beaucoup d'énormes projets qu'il ne finit pas...

Et je suis un peu d'accord avec Thibaut, un peu d'accord avec Kevin. Je pense qu'il faut faire trois benchs, pas moins, pour diminuer les polémiques: un bench avec les mêmes options de compilation; un bench avec les options qui produisent le code le plus efficace en taille; un bench avec les options qui produisent le code le plus efficace en vitesse. Il va sans dire que les benchs doivent être 'transparents' (code source du bench et options de compilation, machine sur laquelle on teste... disponibles pour tout le monde). En général, je le fais (cf ce que j'ai fait l'autre fois pour les fonction de dessin de chaîne de caractères).

en effet c'est ce qui permettrait d'avoir une vision la plus globale des différence entre TIGCC et GTC

Ce n'est pas parce que toi, tu sembles ne pas les utiliser, que personne ne les utilise !

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é

En effet, c'est normal. Ca fait combien de temps qu'il bosse sur GTC ?

Très longtemps(presque dès le début de GTools il me semble) et ca ce comprends. C'est pas du petit boulot surtout quand on est seul.

XDanger
a écrit : Tu sais lire ? Regarde le post 161 !

Oui je l'ai lu, et justement c'est pour ça que je critique (quoi qu'en fait il n'étais pas indispensable).
Mais modere un peu le ton, parceque je n'ai insulté personne (le "tu sais lire" n'est pas une insulte, certes, mais a le même but), et je n'ai même pas parlé un peu "violament". Si cependant tu veux qu'on en arrive là...

XDanger > Ca fait combien de temps qu'il bosse sur GTC ?
Au moins 3 ans. Il en était à 12.000 lignes de code (C68k + ses ajouts) quand j'ai débarqué dans la communauté il y a 3 ans.

> En tout cas, Pollux est connu, et pas seulement sur ce forum, pour commencer beaucoup d'énormes projets qu'il ne finit pas.
GTC est finit. Je l'ai chez moi (j'ai une ancienne version on-calc et la toute dernière on-PC). Il lui reste l'IDE on-calc à fignoler.

> Ce n'est pas parce que toi, tu sembles ne pas les utiliser, que personne ne les utilise !
Moi non plus je ne les utilise pas.


Je suis d'accord pour les tests en trois "modes", je ferai ça quand j'aurais le temps.

Oui je l'ai lu, et justement c'est pour ça que je critique (quoi qu'en fait il n'étais pas indispensable). Mais modere un peu le ton, parceque je n'ai insulté personne (le "tu sais lire" n'est pas une insulte, certes, mais a le même but), et je n'ai même pas parlé un peu "violament". Si cependant tu veux qu'on en arrive là...

OK, je me suis énervé. Je te présente mes excuses pour cela.
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)...

GTC est finit. Je l'ai chez moi (j'ai une ancienne version on-calc et la toute dernière on-PC). Il lui reste l'IDE on-calc à fignoler.

En effet, GTC est presque fini (il n'est donc pas fini ). Mais GTools en tant que tel a été abandonné (une bonne partie du code va se retrouver dans GT-Basic); pareil pour Formula 0 et Bomberman, qui sont pourtant magnifiques d'après les screenshots.

Je suis d'accord pour les tests en trois "modes", je ferai ça quand j'aurais le temps.

OK. Ca me paraît plus juste qu'un seul bench... Egalement, est-ce qu'il serait judicieux de séparer les bench taille en deux parties: sans ROM_CALLs avec F-Line, avec ROM_CALLs avec F-Line ?
Quelqu'un a des idées pour encore plus de benchs différents ?

[EDIT: corrigé le post, il y avait des restes de copier/coller]