TIGCC suggestions - Page 5

registry tout court, sinon registry database

Martial Demolins
: C'est malin, avec mon anglais à 2 balles, il va certainement tout comprendre.

Tu peux aussi lui parler en allemand.

Et à propos du make?

Kevin Kofler
: Nitro, tu n'as pas répondu à une grande partie de mon message. C'est fait exprès parce que tu ne sais plus quoi répondre?

Lol je trouve ça fort. J'ai précisé hier sur IRC que j'avais pas le temps de répondre, comme t'as insisté comme un gros lourdeau j'ai quand même répondu à l'essentiel, et tu trouves encore le moyen de te la rammener... LOL.

Justement, je conçois ça comme une grave erreur de retirer à GCC ses avantages importants sur les autres compilateurs.

Heureusement que tu n'es pas mainteneur de GCC.

et un grand nombre de programmes (surtout ceux qui sont multiplateforme) ne les utilise pas.

TIGCC est multi-plateforme et nous utilisons pas mal d'extensions de GCC.

Et ça change quoi à ce que j'ai dit ?

Néanmoins c'est bien embêtant car les compilateurs qui veulent être compatibles avec les programmes qui utilisent ces extensions (ICC par exemple) sont obligés d'accepter ce dialecte de C.

Tant pis pour eux. Cf. mon "3." ci-dessus.

C'est clair qu'avec ce genre de raisonnement ça donne vachement envie de contribuer à TIGCC.

Ah, si TCC les accepte alors, ça change tout.

Bah, ça veut dire que ce n'est pas aussi bizarre que ça comme idée.

Ça reste non standard.

1. Pas plus "de merde" qu'avant.
2. D'où l'ajout de ces extensions.

Ah, -freg-relative-an ne marchait pas avant ?
Mais c'est sûr qu'il vaut mieux bidouiller là où on peut pour grappiller une poignée d'octets, au lieu de corriger les principaux problèmes que sont le générateur de code de GCC et le manque d'optimisation interprocédurale. Mais bon ne t'en fais pas, je vais m'y mettre. Dès que j'ai fini les cours, je checkout la dernière version de développement de GCC, et j'y integre le résultat de mes travaux au labo concernant les générateurs de code et les optims. On verra bien ce que ça donne.

Les libraries statiques closed source ne sont pas notre problème.

C'est pourquoi dorénavant je code en kernel avec des libs dynamiques. Au moins ce n'est plus mon problème non plus.

nitro
:

Justement, je conçois ça comme une grave erreur de retirer à GCC ses avantages importants sur les autres compilateurs.

Heureusement que tu n'es pas mainteneur de GCC.

Mais je suis mainteneur de TIGCC, donc je peux inverser certains de leurs patches abusifs localement, heureusement.

1. Pas plus "de merde" qu'avant.
2. D'où l'ajout de ces extensions.

Ah, -freg-relative-an ne marchait pas avant ?

Il marchait avant, mais avec un hack exploitant un bogue de obj2ti. Ça utilisait le fait que les relogements 16 bits absolus étaient traîtés comme des relogements relatifs au début du programme. La solution correcte est d'utiliser les relogements négatifs comme on le fait maintenant.

Mais c'est sûr qu'il vaut mieux bidouiller là où on peut pour grappiller une poignée d'octets, au lieu de corriger les principaux problèmes que sont le générateur de code de GCC et le manque d'optimisation interprocédurale.

Les développeurs de GCC travaillent là-dessus (tree-ssa, GCC 4.0 etc.), on ne va pas dupliquer leurs efforts...

Mais bon ne t'en fais pas, je vais m'y mettre. Dès que j'ai fini les cours, je checkout la dernière version de développement de GCC, et j'y integre le résultat de mes travaux au labo concernant les générateurs de code et les optims. On verra bien ce que ça donne.

... ni les tiens. (Si tu les soumets à GCC, on les aura aussi.)

Kevin Kofler
:

GoldenCrystal
: ld-tigcc ne me convient pas parce que c'est un outil non standard,

Bon, c'est comme je disais alors: "parce qu'il n'y a pas écrit 'GNU' devant". C'est malin... Newsflash: GTC n'a pas non plus écrit "GNU" devant, c'est aussi un "outil non standard". Et pourtant tu me sembles bien être de son côté (même remarque pour nitro, d'ailleurs).

Ben j'aime pas le fonctionnement du linker ça me paraît clair non ?

parce qu'il utilise des symbboles pour dfinir son fonctionnement,

Où est le problème?

nom complexes impossibles à retenir, et surtout obligation de modifier la source pour modifier la sortie

parce que c'est une dll,

Pas seulement. Il peut être compilé en exécutable aussi.

Oué mais ça ne l'est pas par défaut. Au moins un package externe avec une version exe serait pas mal.

parce qu'il traffique le code,

That's not a bug, it's a feature. Et c'est complètement optionnel et désactivable!

Nan mais que ce soit désactivable ou pas rien que l'idée qu'il puisse le faire ne m'incite pas à l'utiliser. La gestion du code est à faire dans le compilateur. Si il optimise mal, plutôt que de corriger ça dans le linker c mieux de contribuer à améliorer le compilo non ?

parce qu'il ne génère rien si tu ne définis pas de symbole _ti*** ou _v200,

Les linkers précédents faisaient de même.

Quel bon point de référence

parce que tu n'as pas accès à un stub standard en asm sans définir des symboles au nom immonde...

C'est quoi un "stub standard" selon toi?

ben en assembleur ça serait bêtement un "jmp main"...

3 - Une macro n'est pas la bonne solution.

"pas la bonne solution" pour quoi et pourquoi?

Parce que tu peux faire du code plus souple et tout aussi raisonnable en terme de taille avec une ou deux fonctions, mais là n'est pas le sujet

ça s'adresse pas à moi, mais -> l'éxécutable tigcc n'est pas standard.

Il est compatible avec gcc du point de vue de l'invocation.

Oué mais appeler gcc n'appelera jamais tigcc, ni n'aura exactement les mêmes effets donc...

Oué mais appeler gcc n'appelera jamais tigcc

si, si tu fais la connerie de décompresser le fichier tar.gz (ou bz2, je sais plus) à la racine /

GoldenCrystal :
Ben j'aime pas le fonctionnement du linker ça me paraît clair non ?

Non, c'est toujours très vague.
Mais bon, tu m'en as dit plus sur IRC, heureusement...

parce qu'il utilise des symbboles pour dfinir son fonctionnement,

Où est le problème?

nom complexes impossibles à retenir,

_ti89 est un "nom complexe"?

et surtout obligation de modifier la source pour modifier la sortie

Bah, c'est un peu normal. Si tu veux transformer un programme TI-89 en un programme TI-92+, ou un programme qui ne sauvegarde pas l'écran en un programme qui sauvegarde l'écran, tu dois changer la source, tout comme si tu veux changer un "Hello world!" en un "Hello GoldenCrystal!". (Et d'ailleurs, ce n'est même pas le cas en C où il suffit de changer les paramètres -D, juste en assembleur.)

parce que c'est une dll,

Pas seulement. Il peut être compilé en exécutable aussi.

Oué mais ça ne l'est pas par défaut. Au moins un package externe avec une version exe serait pas mal.

Il y aura probablement un paquet "TIGCC 0.95 Alternative Files" contenant entre autres ld-tigcc.exe et ar-tigcc.exe. Tout comme il y a eu des paquets "Alternative Files" avant.
En attendant, ces binaires sont disponibles sur demande par e-mail (à moi).

Nan mais que ce soit désactivable ou pas rien que l'idée qu'il puisse le faire ne m'incite pas à l'utiliser. La gestion du code est à faire dans le compilateur. Si il optimise mal, plutôt que de corriger ça dans le linker c mieux de contribuer à améliorer le compilo non ?

Tu montres par cela que tu n'as rien compris à comment fonctionne l'optimisation du linker!
Le but de l'optimisation linker est d'optimiser ce qui ne peut pas être optimisé par le compilateur ou l'assembleur: les références d'un fichier objet à un autre (ou d'une section à une autre). Les distances ne sont connues qu'en temps de linking, donc seul le linker peut savoir si on peut adresser en PC-relatif voire en branchement court.
Je me demande combien de fois il faudra que je répète cela pour que ça rentre dans la tête de certains! Je sens que je vais le mettre dans la FAQ de TIGCC...

parce qu'il ne génère rien si tu ne définis pas de symbole _ti*** ou _v200,

Les linkers précédents faisaient de même.

Quel bon point de référence

La compatibilité antérieure, tu connais?

parce que tu n'as pas accès à un stub standard en asm sans définir des symboles au nom immonde...

C'est quoi un "stub standard" selon toi?

ben en assembleur ça serait bêtement un "jmp main"...

.xdef __ref_all___startup_code;.xdef __ref_all___nostub
Les noms ne sont pas immondes:
* __ref_all_: global import, cf. doc
* __startup_code: code de démarrage
* __nostub: _nostub (c'est-à-dire qu'on veut le code de démarrage pour le mode _nostub)

3 - Une macro n'est pas la bonne solution.

"pas la bonne solution" pour quoi et pourquoi?

Parce que tu peux faire du code plus souple et tout aussi raisonnable en terme de taille avec une ou deux fonctions, mais là n'est pas le sujet

Je n'ai toujours pas compris le contexte de ta phrase! Tu parles de quoi? Qu'est-ce pour quoi une macro n'est pas la bonne solution selon toi?

Oué mais appeler gcc n'appelera jamais tigcc, ni n'aura exactement les mêmes effets donc...

Ben évidemment, sinon on utiliserait gcc et pas tigcc. Le but est d'avoir un "compiler driver" invocation-compatible avec gcc, mais gérant notre target correctement.

Kevin Kofler
:

Nan mais que ce soit désactivable ou pas rien que l'idée qu'il puisse le faire ne m'incite pas à l'utiliser. La gestion du code est à faire dans le compilateur. Si il optimise mal, plutôt que de corriger ça dans le linker c mieux de contribuer à améliorer le compilo non ?

Tu montres par cela que tu n'as rien compris à comment fonctionne l'optimisation du linker!
Le but de l'optimisation linker est d'optimiser ce qui ne peut pas être optimisé par le compilateur ou l'assembleur: les références d'un fichier objet à un autre (ou d'une section à une autre). Les distances ne sont connues qu'en temps de linking, donc seul le linker peut savoir si on peut adresser en PC-relatif voire en branchement court. Je me demande combien de fois il faudra que je répète cela pour que ça rentre dans la tête de certains! Je sens que je vais le mettre dans la FAQ de TIGCC...

N'importe quoi, tu présentes le fait que le linker fasse des optimisations "dangereuses" comme une fatalité. Il suffit de garder suffisamment d'informations en plus du code objet "de base" pour pouvoir générer du code sûr. Là, vous avez fait le travail à moitié, en rajoutant des informations de relocations relatives, mais sans pour autant rendre ces optimisations sûres.

Accessoirement, se limiter à un format binaire ne permet pas des optimisations plus poussées, donc c pas forcément une bonne idée (j'étais à l'instant en train de me remettre à GTC II, et les quelques tests préliminaires que j'ai faits me laissent penser que l'optimisation va pouvoir faire plein de trucs qui ne sont pas possibles avec un modèle de compilation séparée traditionnel ^^)
Donc bon, moi je vois ça plus comme un hack temporaire qu'autre chose...

langage intermédiaire powa

je sens que l'idée de Pollux est un poil plus complexe que ça ^^

GTC II? w00t

2048 powered

GoldenCrystal :
langage intermédiaire powa

oui, mais bon en fait n'importe quelle représentation qui garde assez d'infos pour pas casser le code suffit, y a le choix ^^ (ça pourrait même être tout bêtement un .asm ou un .s, ça marcherait très bien et il n'y aurait pas eu besoin d'implémenter toutes ces "optimisations" avec des heuristiques douteuses)

Godzil :
je sens que l'idée de Pollux est un poil plus complexe que ça ^^

Ben je compte utiliser des graphes comme langage intermédiaire, ça va me permettre des analyses d'aliasing assez poussées (et des trucs comme la propagation de copies, de constantes ou encore l'élimination d'expressions communes sont des conséquences triviales de la représentation d'une fonction)
Si j'ai le tps, ça va même me permettre de faire des strength reductions (for (int i=0;i<10;i++) p[i]++; => loop: addq.w #1,(a0)+; dbf d0,loop), d'optimiser le placement des variables globales (var1 = 2; var7 = 5; => move.l #(2<<16)+5,(a0)), etc...

Mais bon, stop le off-topic ^^

Peut-être qu'un jour TIGCC utilisera LLVM, qui équivaudrait à peu près à ce que fait Pollux avec GTC II. Mais je juge que LLVM n'est pas assez avancée pour être utile à TIGCC actuellement. Les exécutables risquent d'être plus gros avec LLVM que sans.

Mais rien de cela ne pourra complètement remplacer la compilation séparée et le linking traditionnel (il suffit de penser aux fichiers en assembleur, par exemple).

Et même s'il y a théoriquement d'autres solutions (peut-être meilleures), le fait est qu'avec un modèle de linking traditionnel, il n'est pas possible d'optimiser certaines choses autrement qu'avec le système d'optimisation linker qu'on utilise. Si on a décidé d'optimiser certaines choses dans le linker, ce n'est pas pour nous amuser.

Oh, et pas besoin de changer radicalement la représentation pour éliminer les rarissimes "faux positifs" de l'optimisation linker, il suffit de rajouter encore quelques extensions mineures au format des fichiers objet et à l'assembleur, pour que le linker sache quels relogements sont optimisables et lesquels ne le sont pas. Je sens que je vais m'y mettre un de ces jours pour que les trolls "optimisations pas sûres" perdent leur fondement, aussi ridicules qu'ils soient (la probabilité d'erreur est vraiment faible).

PS: Je m'y suis mis là. Flag "unoptimizable" implémenté dans le linker, en attente de commentaires de Sebastian. Gestion dans l'assembleur GNU encore à implémenter. Pour A68k, je verrai plus tard.

Et au fait, les paranos, j'ai une nouvelle pour vous: les mots de passe MD5 ne sont pas non plus "sûrs", il y a une probabilité de 2^-126 que votre mot de passe ait le même MD5 que "test", "1234", "0000" ou "password".

Kevin Kofler
: Mais rien de cela ne pourra complètement remplacer la compilation séparée et le linking traditionnel (il suffit de penser aux fichiers en assembleur, par exemple).

Comment ça ? Il suffit d'inclure aussi le code assembleur là-dedans.

Et même s'il y a théoriquement d'autres solutions (peut-être meilleures), le fait est qu'avec un modèle de linking traditionnel, il n'est pas possible d'optimiser certaines choses autrement qu'avec le système d'optimisation linker qu'on utilise. Si on a décidé d'optimiser certaines choses dans le linker, ce n'est pas pour nous amuser.

Quelles choses ?

Kevin Kofler :
Et au fait, les paranos, j'ai une nouvelle pour vous: les mots de passe MD5 ne sont pas non plus "sûrs", il y a une probabilité de 2^-126 que votre mot de passe ait le même MD5 que "test", "1234", "0000" ou "password".

Bouh Comment tu sais qu'il y a 2 bits de perdus ?

Tu sais Kevin il existe un bouton "Editer" pour éviter de poster 3 fois de suite...

Pollux
:

Kevin Kofler
: Mais rien de cela ne pourra complètement remplacer la compilation séparée et le linking traditionnel (il suffit de penser aux fichiers en assembleur, par exemple).

Comment ça ? Il suffit d'inclure aussi le code assembleur là-dedans.

Du coup, ce n'est plus de l'assembleur! Du moins avec la représentation interne de LLVM. Tu en as peut-être une meilleure.

Et même s'il y a théoriquement d'autres solutions (peut-être meilleures), le fait est qu'avec un modèle de linking traditionnel, il n'est pas possible d'optimiser certaines choses autrement qu'avec le système d'optimisation linker qu'on utilise. Si on a décidé d'optimiser certaines choses dans le linker, ce n'est pas pour nous amuser.

Quelles choses ?

Références d'un fichier objet à un autre.

Kevin Kofler :
Et au fait, les paranos, j'ai une nouvelle pour vous: les mots de passe MD5 ne sont pas non plus "sûrs", il y a une probabilité de 2^-126 que votre mot de passe ait le même MD5 que "test", "1234", "0000" ou "password".

Bouh Comment tu sais qu'il y a 2 bits de perdus ?

4/2¹²⁸=2^-126
(Mais j'avoue ne pas avoir vérifié que mes 4 exemples ont des MD5 différents.)

Kevin Kofler
:

Pollux
:

Kevin Kofler
: Mais rien de cela ne pourra complètement remplacer la compilation séparée et le linking traditionnel (il suffit de penser aux fichiers en assembleur, par exemple).

Comment ça ? Il suffit d'inclure aussi le code assembleur là-dedans.

Du coup, ce n'est plus de l'assembleur! Du moins avec la représentation interne de LLVM. Tu en as peut-être une meilleure.

Je ne propose pas de modifier le code assembleur, juste d'avoir une représentation interne qui autorise *et* des trucs de haut niveau *et* des trucs de bas niveau (quitte à ce que les trucs bas niveau soient en read-only).

Et même s'il y a théoriquement d'autres solutions (peut-être meilleures), le fait est qu'avec un modèle de linking traditionnel, il n'est pas possible d'optimiser certaines choses autrement qu'avec le système d'optimisation linker qu'on utilise. Si on a décidé d'optimiser certaines choses dans le linker, ce n'est pas pour nous amuser.

Quelles choses ?

Références d'un fichier objet à un autre.

Oui mais encore une fois ça n'a pas besoin d'opérer sur du code objet.

Kevin Kofler :
Et au fait, les paranos, j'ai une nouvelle pour vous: les mots de passe MD5 ne sont pas non plus "sûrs", il y a une probabilité de 2^-126 que votre mot de passe ait le même MD5 que "test", "1234", "0000" ou "password".

Bouh Comment tu sais qu'il y a 2 bits de perdus ?

4/2¹²⁸=2^-126
(Mais j'avoue ne pas avoir vérifié que mes 4 exemples ont des MD5 différents.)

Ah, j'avais compris 2^-126 pour chacun (ce qui aurait été un gros gros défaut du MD5, notamment si on utilise pas les 128 bits en entier)
Et la "probabilité" que la définition de la sémantique de bsr ne coïncide pas avec celle décrétée par TIGCC (et qui change à chaque release, d'ailleurs) est relativement élevée (rien que dans le stub de lancement des progs kernel on trouve ce genre de code...)

Pollux
: Je ne propose pas de modifier le code assembleur, juste d'avoir une représentation interne qui autorise *et* des trucs de haut niveau *et* des trucs de bas niveau (quitte à ce que les trucs bas niveau soient en read-only).

"En read-only"? C'est-à-dire que les références d'un fichier objet codé en assembleur à un autre ne seraient pas optimisables?
Le code de démarrage de tigcc.a en souffirirait beaucoup si c'était comme ça!

Oui mais encore une fois ça n'a pas besoin d'opérer sur du code objet.

Dans un système de linking classique, si. Si on change tout, à la LLVM ou GTC II, alors non, en effet.

Et la "probabilité" que la définition de la sémantique de bsr ne coïncide pas avec celle décrétée par TIGCC (et qui change à chaque release, d'ailleurs) est relativement élevée (rien que dans le stub de lancement des progs kernel on trouve ce genre de code...)

Bon, tu mélanges plusieurs problèmes là:
1. Les bsr+rts->bra. Optimisation désactivable si elle te dérange. Et facilement contournable aussi (il suffit de mettre un label bidon entre les deux). C'est vrai qu'il vaudrait mieux la faire dans le compilateur et pour le C seulement, mais en attendant, ça marche très bien.
2. Le bsr.w du header kernel. Ce bsr n'est pas susceptible à une optimisation bsr+rts->bra. Il serait susceptible à une optimisation bsr.w->bsr.s, mais c'est pour ça que le header kernel est déclaré comme une section de données (ce qu'il est: il y a une seule instruction de code, et elle n'est pas optimisable comme une instruction, donc elle est aussi à considérer comme une donnée). Donc aucun problème ici.
3. Le bsr du stub kernel, pour placer le message "Kernel required" sur la pile. Ce bsr n'est pas touché par l'optimisation bsr+rts->bra et ne le serait pas même pour un message d'erreur commençant par "Nu" parce qu'il y a un label devant le message. Quant aux optimisations bsr.w->bsr.s, elles sont valides dans le stub. Donc aucun problème ici.


Et sinon, j'ai fini d'implémenter mon flag "Unoptimizable" pour les sources GNU as, donc l'optimisation est maintenant (dès la prochaine bêta si Sebastian accepte mes patches tels quels) sure à 100% pour toutes les sources en C ou assembleur GNU.

un truc qui a rien a voir :
tt a lheure j'ai voulu commencer un nouveau mario, j'ai ecris la moitié des sprites et le code gerant mon mario et la jme dis qu'il faut que je le sauvegarde et que je le teste, donc je fais alt F9 comme d'habitude et il me sort la ptit fenetre "save menu" je rentre le nom et au moment ou je clique sur enrengistrer ... plout ! , black-out, ecran noir où l'on voit mon reflet vert ...
bon je me dis que c'est pas grave et je rallume mon pc ...
demarrage de windows-post bug normal avec l'execution du chkdsk puis au moment où j'ai a nouveau la main plouuut ! second ecran noir, apres 4 ou 5 ecran noir ou l'on voit mon reflet bleu j'attein enfin mon bureau adoré, je clique sur l'icone tigcc -> new project -> alt f9 ... écran noir a nouveau
bon la jme dis c'est rien ... puis apres 46 demarrage je reinstalle tigcc et je reteste la compilation, encore ecran noir ....
bon la ca devient critique parceque j'ai besoin de au moins 10 demmarage pour acceder a mon pc ...
et ce qui fait vraiment chier c'est que j'ai fait un magnifique programme qui simplifie des expressions avec les tableaux de karnaugh et que j'ai terminé y'a qq heures mais tout n'est pas mis en place, j'ai plein de code en commentaire ..
et mon ds de SI est demain!!!! et je sais que j'aurais 25 expressions a simplifier minimum

aidez moi svp, je peux pas reinstaller windows ce soir ce serait trop long....

bon ba c parti pour une reinstallation total !!

Kevin Kofler
:

Pollux
: Je ne propose pas de modifier le code assembleur, juste d'avoir une représentation interne qui autorise *et* des trucs de haut niveau *et* des trucs de bas niveau (quitte à ce que les trucs bas niveau soient en read-only).

"En read-only"? C'est-à-dire que les références d'un fichier objet codé en assembleur à un autre ne seraient pas optimisables?
Le code de démarrage de tigcc.a en souffirirait beaucoup si c'était comme ça!

Non, en read-only veut dire qu'on ne modifie pas les opcodes (comme si c'était le cas si on transformait "add.w" en le même format intermédiaire que le code C), mais qu'on ne fixe pas pour autant la forme binaire.

Et sinon, j'ai fini d'implémenter mon flag "Unoptimizable" pour les sources GNU as, donc l'optimisation est maintenant (dès la prochaine bêta si Sebastian accepte mes patches tels quels) sure à 100% pour toutes les sources en C ou assembleur GNU.

Bah voilà Sauf qu'il manque encore le support A68k.

Pollux
:

Et sinon, j'ai fini d'implémenter mon flag "Unoptimizable" pour les sources GNU as, donc l'optimisation est maintenant (dès la prochaine bêta si Sebastian accepte mes patches tels quels) sure à 100% pour toutes les sources en C ou assembleur GNU.

Bah voilà Sauf qu'il manque encore le support A68k.

Hmmm... Faut pas y compter. J'ai en moins en moins envie de rajouter des trucs à A68k, vu qu'il est vraiment obsolète. J'ai déjà rajouté des trucs comme le mode all-relocs qui ont transformé le code de A68k en véritable bordel vu que ce n'était pas du tout prévu, et c'est vraiment lourd à maintenir. Pourquoi pas utiliser l'assembleur GNU, tout simplement?