pointeur de fonction - Page 2

Non, commentaire parfaitement objectif.

Justement, c'est tout l'intérêt de la chose. La seule différence entre GTC et TIGCC au niveau du multi-objet est que TIGCC crée un fichier objet qui correspond au binaire du programme + qques relocs (+ toutes les références relatives dans 0.95), alors que GTC ne génère le code qu'après avoir tout parsé (rien n'empêcherait dans une version future de stocker les résultats du parsing dans un fichier externe pour bénéficier du seul intérêt du multi-objet que GTC ne gère pas pour l'instant, à savoir la rediffusion de parties du programme).

Résultat, le compilateur a toute la liberté de faire des optimisations globales - par exemple, modifier les conventions d'appel, avoir des variables globales automatiquement dans des registres, et encore beaucoup d'autres choses. Ce genre d'optimisation est qd même compliqué à implémenter, donc ce n'est que pour GTC 1.0 (refonte totale du générateur de code, qui permettra entre autres d'avoir une liberté totale dans l'allocation de registres).


Kevin> Je ne ferai évidemment aucun commentaire sur ceci :

Pollux ne s'est apparemment jamais posé cette question.

Pollux est le spécialiste des extensions mal réfléchies et complètement inadaptables à un compilateur qui n'a pas la même structure interne que le sien

Au fait, GCC 3.4 permettra aussi de compiler plusieurs fichiers .c en même temps. Mais je ne sais pas s'il sera facile d'utiliser ça avec TIGCC.

Et après tu viens critiquer GTC sous prétexte que je fais des trucs "mal réfléchis" ??? Si j'implémente quelque chose de nouveau, c'est parce que je suis un débile profond et que je ne sais pas ce que c'est que le C (cf nombreux posts de "critique préventive" sur asm { } et les prétendues incompatibilités avec le préprocesseur), et si GCC le fait, c'est le "standard" donc c'est la Vérité Suprême ?

Enfin, heureusement que GCC 3.4 implémentera des optimisations globales sinon GTC aurait été complètement non-standard et donc à prohiber totalement

Pollux
: Et après tu viens critiquer GTC sous prétexte que je fais des trucs "mal réfléchis" ???

Oui! Ta solution ne marche que en compilant tout en même temps. GCC est flexible et permet la compilation séparée (et continuera à la permettre; elle n'est pas prête à disparaître même avec GCC 3.4! La compilation séparée permet de gagner beaucoup de temps de compilation et de créer des librairies statiques), donc ses développeurs ne peuvent pas se permettre de rendre leur langage totalement dépendant d'un style particulier de compilation (je signale à ce sujet que les optimisations globales de GCC 3.4 se limitent pour l'instant à de l'inlining entre fonctions de différents fichiers .c). Et ceci (limiter le langage à un style particulier de compilation) est exactement ce que font tes propositions. Donc oui, ce sont des idées mal réfléchies.

Et d'ailleurs, il marche comment ton "OPTIMIZE_ROM_CALLS automatique"? 1. Fonction par fonction ou 2. globalement (un même registre utilisé partout quand le compilateur le juge intelligent)? Les 2 cas sont sous-optimaux. Dans le cas 1, tu as des move.l 0xc8,%an parasites au début de chaque fonction, qui ne sont pas là en mode OPTIMIZE_ROM_CALLS. Dans le cas 2, la remarque du paragraphe ci-dessus s'applique.

Et j'insiste sur le suivant:

Kevin Kofler :
Pollux est le spécialiste des extensions mal réfléchies et complètement inadaptables à un compilateur qui n'a pas la même structure interne que le sien, ce qui risque de lui retomber dessus quand il voudra modifier cette structure interne.

Pollux, crois-moi, tôt ou tard, tu vas vouloir implémenter la compilation séparée, et tu vas être bien embêté à cause de tes propres extensions mal réfléchies.
Et ce n'est pas le seul point susceptible de changer avec lequel tes extensions pourraient entrer en conflit. La structure d'un compilateur change avec le temps. Regarde GCC, sa structure interne a changé beaucoup au cours du temps.

Bref, tu penses beaucoup trop à court terme. Essaye de penser à long terme. D'autant plus que ton compilateur en aura besoin, du long terme, vu le temps que tu mets à le sortir. Tu pensais l'avoir prêt avant TIGCC 0.95 bêta 1, et ben, c'est râté. Et cela malgré le fait que nous avons mis plus longtemps que j'avais pensé (mais pas annoncé! Je fais beaucoup plus attention à ce que j'annonce comme dates de sortie que toi).

Oui! Ta solution ne marche que en compilant tout en même temps. GCC est flexible et permet la compilation séparée (et continuera à la permettre; elle n'est pas prête à disparaître même avec GCC 3.4! La compilation séparée permet de gagner beaucoup de temps de compilation et de créer des librairies statiques), donc ses développeurs ne peuvent pas se permettre de rendre leur langage totalement dépendant d'un style particulier de compilation (je signale à ce sujet que les optimisations globales de GCC 3.4 se limitent pour l'instant à de l'inlining entre fonctions de différents fichiers .c). Et ceci (limiter le langage à un style particulier de compilation) est exactement ce que font tes propositions. Donc oui, ce sont des idées mal réfléchies.

Depuis quand le fait de rajouter des optimisations sans extensions de langage est une incompatibilité??? Je ne vois absolument pas le problème que GTC permette une compilation plus efficace quand elle est possible. Donc :
- même si elle n'était pas toujours possible, elle pourrait déjà améliorer le code dans les cas où elle est possible
- comme je l'ai dit plus haut, ça n'empêche absolument pas les libs statiques : au lieu de stocker un binaire et une table de relocs comme fichier objet, on stocke un code intermédiaire
- enfin, même sans ça ça n'empêcherait pas de faire des libs statiques dont on ne redistribue que des binaires - on ne profite pas des optimisations pour le code de la lib en elle-même, sauf pour les fonctions 'static', mais on en profite pour le reste du programme

Et d'ailleurs, il marche comment ton "OPTIMIZE_ROM_CALLS automatique"? 1. Fonction par fonction ou 2. globalement (un même registre utilisé partout quand le compilateur le juge intelligent)? Les 2 cas sont sous-optimaux. Dans le cas 1, tu as des move.l 0xc8,%an parasites au début de chaque fonction, qui ne sont pas là en mode OPTIMIZE_ROM_CALLS. Dans le cas 2, la remarque du paragraphe ci-dessus s'applique.

La solution 1. est déjà implémentée depuis belle lurette par le CSE de GTC (et elle est loin d'être aussi inefficace que tu le prétends), je parlais donc de la solution 2. Et évidemment, dans ce cas, ma réponse à ta remarque du dessus s'applique

Pollux, crois-moi, tôt ou tard, tu vas vouloir implémenter la compilation séparée, et tu vas être bien embêté à cause de tes propres extensions mal réfléchies.

Encore une fois, je ne vois pas en quoi une optimisation apporterait une incompatibilité. Ce genre d'optimisation n'est appliqué que lorsque c'est possible, point.

Et ce n'est pas le seul point susceptible de changer avec lequel tes extensions pourraient entrer en conflit. La structure d'un compilateur change avec le temps. Regarde GCC, sa structure interne a changé beaucoup au cours du temps.

Crois-moi, je fais probablement bien plus attention à la structure interne que vous. Par exemple, les optimisations globales seront effectuées par un générateur de code refait à partir de zéro (donc structure interne 100% différente, même l'arbre d'expressions sera stocké différement), et il restera pourtant compatible avec la version PC actuelle et la version on-calc.
D'ailleurs, la plupart des choses qui manquent à GTC ne sont pas implémentées parce que la version on-calc ne les supporterait pas, et donc il n'y aurait pas compatibilité à 100% avec la version PC.

Bref, tu penses beaucoup trop à court terme. Essaye de penser à long terme.

No comment. Tu te la joues gros boss alors que tu n'as pas sorti un seul argument convaincant.

Il est toujours aussi modeste et son agressivité montre combien il est énervé que tu sortes un compilateur meilleur sur certains points que le "sien"...

La compilation séparée permet de gagner beaucoup de temps de compilation

Temps minimum pour la compilation complète d'Einstein avec TIGCC sur un Athlon XP 2400+ : 4 secondes 30.
Temps minimum pour la compilation complète d'Einstein avec GTC sur le même ordinateur : < 1/4 seconde.

Pour concrétiser, on peut dire que GTC a le temps de compiler 18 fichiers .c pendant que TIGCC n'en compile qu'1 seul............ alors ton argument =>


[edit] je devine d'avance ta réponse. J'y répond : "trouve-nous un projet C pour TI68k qui comporte plus de 18 fichiers..."
Même si t'en trouves, ils sont très rares...
De toute façon, la compilation séprarée viendra sûrement.

et de créer des librairies statiques

Ca viendra !

Ton principal "argument" pour justifier ta haine (débile. Je te rappelle que tu es le seul) contre GTC c'est qu'il ne gère pas telle extension, telle optimisation, ...
Combien de fois va-t-il falloir encore répéter pour que ton petit cerveau comprenne que GTC a des contraintes matérielles à considérer ET qu'il n'en est qu'à ses premières versions, qu'heureusement il va évoluer ?

Et toi tu es le seul à toujours déterrer des topics pour le relancer. Tu le provoques exprès, et tu t'étonnes qu'il marche ? Faut pas exagérer non plus
Et tous tes arguments en faveur de GTC se heurtent à un poblème majeur: pour le commun des mortels, GTC n'existe pas ...

Je m'étonne pas qu'il marche, je sais très bien qu'il trouve toujours à répondre ! Où t'es allé cherché ça, toi...
Je déterre pour répondre à des choses qu'il ne faut pas laisser passer à mon sens : Kevin a une opinion exagérément négative. Alors on débat. Si le débat ne te plaît pas, tu ne lis pas ce topic, mais laisse-nous discuter...
Et pour la deuxième ligne de ton post : et alors ? ça n'empêche pas de discuter de ses fonctionnalités en partant du principe qu'il existe, la preuve D'ailleurs, tu peux demander une bêta à Pollux, s'il te juge digne de confiance.

Thibaut, tu te répètes, j'ai déjà répondu à tes 2 points du ./38 (rappel: si le projet a trop peu de fichiers pour que la compilation séparée soit efficace, on le découpe; avec le nouveau linker, ça ne coûte rien) et je n'ai pas envie de me répéter.

Excuse-moi, mais je crois que Thibaut n'a à aucun moment dit que le système de GTC était plus efficace que celui de TIGCC, donc ta critique n'a pas lieu d'être ; il dit simplement que le système de GTC n'est pas moins efficace.

D'ailleurs, ce système n'apportera des avantages qu'avec le nouveau générateur de code, pas avec l'actuel.

Kevin : Je ne comprends pas ta réponse.
Imaginons que j'ai un projet de 10 fichiers.
Je fais une modification dans un fichier.
Je lance la compilation avec TIGCC : il a juste à recompiler le fichier modifié, ce qui prend, disons, 1 seconde.
Je lance la compilation avec GTC : il recompile tout, ce qui prend 1*10/18= 0,56 seconde.

Les faits sont bien là : pour des projets de moins de 18 fichiers, la compilation avec GTC est plus rapide ! non ?

Rien ne t'empêche de couper tes 10 fichiers en encore plus de morceaux.

Ben après çe ne devient pas plus pratique...

Ni plus rapide.

Oui. Réponse ridicule.
Je crois qu'il faut que tu oublies ta haine irréfléchie et que tu acceptes de reconnaître les qualités de GTC, ce sera plus adulte... je veux bien qu'on me dise que je suis gamin, mais t'es pas mal non-plus

PpHd
: Ni plus rapide.

Si.

BASH-2.05b$ time tigcc -S empty.c

real    0m0.818s
user    0m0.000s
sys     0m0.000s

On peut donc descendre en-dessous d'une seconde par fichier. Et cette mesure inclut tout le passage par le frontend.

NiPuteNiSoumise
: Oui. Réponse ridicule.

Non, réponse justifiée, cf. timing.

Je crois qu'il faut que tu oublies ta haine irréfléchie et que tu acceptes de reconnaître les qualités de TIGCC, ce sera plus adulte...

Pff toujours aussi ridicule ! je répondais en fonction de ce qu'a dit Sasume.
Vas-y, puisque pour toi c'est une solution pour dépasser GTC : découpe ton Backimmonde () en 50 fichiers...
Ou trouve-nous un projet où il n'y a qu'une ou deux fonctions par fichier...

il faut que tu oublies ta haine irréfléchie et que tu acceptes de reconnaître les qualités de TIGCC

Allons bon. Quelles qualités je refuse de reconnaître à TIGCC ? La qualité qu'il est plus lent ? La qualité qu'il optimise moins bien en taille ?
Quelles qualités remarquables !!!
Il ne me semble pas soutenir que TIGCC est une merde et refuser de voir ses avantages, contrairement à toi qui est catégorique et menteur à propos de GTC. Trouves-nous le ou les posts où tu m'as vu avoir ce comportement envers TIGCC... Ne sors pas l'histoire de rowread, je me suis excusé après avoir reconnu ma bêtise !

C'est pas très adulte de sortir des réponses aussi stupides que "t'as qu'à découper pour avoir 50 fichiers" (c'est pas la première fois que tu préfères sortir une grosse connerie au lieu de te montrer humble et accepter ton erreur) ou de reprendre les critiques qu'on te fait en guise de réponse sans y réfléchir et te remettre en cause (fierté, prétention ?).

- Dans la pratique,
- avec des projets découpés de manière pratique,
- de moins de 15 fichiers,
c'est à dire pour presque tous les projets, le fait que GTC compile tout d'un coup n'est pas regrettable en terme de temps de compilation, cf. données du post #42.

Il n'y a que l'impossibilité de faire des bibliothèques statiques qui est handicapant. Mais ça viendra. GTC va heureusement évoluer. TIGCC a heureusement évolué aussi depuis ses débuts.

GTC n'existe pas.

[b]c:\gtc[/b]
de mon dd n'existe pas alors ?
ah, bon, je dosi avoir des hallu alors !!

geogeo : ce n'est pas une réponse au problème ! Tu dévies sur un autre problème qui ne change rien au nôtre : en admettant que GTC existe, Kevin décide de mener une croisade contre ce "concurrent" à coups de descriptions inobjectives ou de réponses idiotes.

Mais c'est normale, tu crois qu'il va ce mettre à genoux devant GTC????
Si GTC sors, TIGCC aura un concurrent et ça laissera un choix au programmeur en ASM/C sur TI68K.
Mais de là ce défendre sur un programme que soit disant une minorité de personnes possède et dont le reste ne peux pas juger et vérifier ce qui est dit, c'est la possibilitée de dire n'importe quoi.

NiPuteNiSoumise :
Vas-y, puisque pour toi c'est une solution pour dépasser GTC : découpe ton [Backgammon (sans commentaire pour ta manière de l'appeler )] en 50 fichiers...

Pourquoi pas? Je pourrais facilement le faire. Mais personnellement je me contrefiche du temps de compilation (je ne vois pas du tout pourquoi vous vous en plaignez tant...), et donc je ne vois pas l'intérêt de le faire.

Ou trouve-nous un projet où il n'y a qu'une ou deux fonctions par fichier...

TIGCCLIB
Et je peux facilement faire la même chose pour Backgammon.

il faut que tu oublies ta haine irréfléchie et que tu acceptes de reconnaître les qualités de TIGCC

Allons bon. Quelles qualités je refuse de reconnaître à TIGCC ? La qualité qu'il est plus lent ?

Non, la qualité qu'il gère la compilation séparée.

La qualité qu'il optimise moins bien en taille ?

Non, la qualité qu'il optimise mieux en général. Tu peux toujours trouver des fichiers particuliers sur lesquels son résultat n'est pas optimal, mais il suffit de regarder la liste des optimisations gérées pour voir que GCC est largement techniquement supérieur à GTools Compiler.

Et aussi les qualités:
* qu'il gère bien plus de constructions de langage, dont certaines qui permettent d'optimiser mieux le code.
* qu'il est le standard de facto établi, et que donc les programmes sont écrits pour lui.
D'après ce qu'on m'a dit, Backgammon ne compile même pas avec GTools Compiler à cause des constructions non gérées ou gérées de manière incompatible avec le standard de facto. Donc pour comparer, ben c'est raté. Dans un comparatif, le compilateur qui ne compile pas la source, ben il se prend un 0 tout rond, évidemment. Il faudra que tu comprennes qu'il y a des choses plus importantes que la performance pure (que ce soit en temps de compilation ou d'exécution).

Il ne me semble pas soutenir que TIGCC est une merde et refuser de voir ses avantages,

Si, tu le fais constamment. Le fait que tu ne t'en rendes même pas compte est grave, ou pour reprendre tes propres mots: "dangereux".

contrairement à toi qui est catégorique et menteur à propos de GTC.

N'importe quoi! Où ai-je menti??? Tout ce que j'ai dit est vrai!

C'est pas très adulte de sortir des réponses aussi stupides que "t'as qu'à découper pour avoir 50 fichiers"

Ce n'est pas du tout une réponse stupide, c'est une solution pratique et logique au problème du temps de compilation.

(c'est pas la première fois que tu préfères sortir une grosse connerie au lieu de te montrer humble et accepter ton erreur)

Argumentation invalide. Je te donne une solution intelligente à laquelle tu n'avais pas pensé, donc tu la déclasses au rang de c*nnerie plutôt que d'admettre ton incompétence qui t'a fait passer à côté de cette solution et par conséquent t'enfoncer dans une argumentation foireuse.

- Dans la pratique,
- avec des projets découpés de manière pratique,
- de moins de 15 fichiers, c'est à dire pour presque tous les projets,

Non, ce ne sont pas "presque tous les projets". Un projet optimisé pour TIGCC 0.95 n'aura pas cet aspect-là. Mets-toi dans ta tête que le découpage de la source n'est pas une caractéristique statique d'un projet, ça se change facilement en quelques minutes (couper-coller).

le fait que GTC compile tout d'un coup n'est pas regrettable en terme de temps de compilation, cf. données du post #42.

Cf. mes réponses.

Il n'y a que l'impossibilité de faire des bibliothèques statiques qui est handicapant.

Personnellement, j'appellerais plutôt ça "inacceptable" que juste "handicapant".

geogeo :
GTC n'existe pas.

Dis plutôt qu'on ne l'a pas.
Je sais qu'il existe parce que Sebastian m'a dit qu'il en a eu une bêta, et Sebastian est une personne à laquelle je fais confiance (contrairement à Pollux et Thibaut).

BASH-2.05b$ time tigcc -S empty.c

real    0m0.818s
user    0m0.000s
sys     0m0.000s

Oh comme c'est gentil de me donner un argument tout trouvé
Tu viens de nous dire que la compilation (sans assemblage!) d'un fichier vide (je suppose qu'il inclut qd même <tigcclib.h> ?) prenait quasiment une seconde... Donc si tu découpais TI-Chess en 50 fichiers, en plus des 20 secondes que prend la compilation lorsque tous les fichiers sont regroupés, tu dois rajouter une seconde par fichier? Ca fait plus d'une minute de compilation si on veut tout recompiler (modification d'un .h par exemple). Et si on ne recompile qu'un seul fichier, ça fait quand même 1 seconde pour le compiler, et c'est plus que GTC pour tout recompiler (bon cela dit dans cet ordre de grandeur de temps ça ne change plus grand chose... le problème se situe surtout au niveau des modifications de .h [ajout d'une fonction, modification d'une option de compilation], où là il faut tout recompiler )

Pollux
: Tu viens de nous dire que la compilation (sans assemblage!) d'un fichier vide (je suppose qu'il inclut qd même <tigcclib.h> ?)

Non, c'était un fichier de 0 octets.

Mais il arrive rarement qu'on ait à tout recompiler. Normalement, il y a juste un fichier à recompiler, et mon test montre que ça prend moins d'une seconde s'il est suffisamment petit.
Et n'oublie pas que c'est sur un PIII 733, pas sur un Athlon 2 GHz...

Et puis dans mon chronométrage, il y avait aussi le lancement et le traîtement d'arguments de tigcc.exe. Si on utilise l'IDE pour le Project/Make, ces initialisations ne sont faites qu'une fois pour tout le projet, pas une fois par fichier.