TIGCC 0.95 Beta 6 - Page 5

--- pardon ---

Flanker :
J'aime tes contradictions :
tu refuses d'utiliser un programme qui n'est pas sûr à 100%, et en même temps tu proposes des optimisations qui elles mêmes ne sont pas sures à 100%
Déjà, c'est Sebastian qui a introduit ces optimisations. Ce que j'ai rajouté, moi, c'est le range-cutting, qui permet de gagner en taille du code lui-même et pas juste en nombre de relogements. Et puis, c'est sûr à au moins 99% (tes cas ne comptent pas parce que tu n'as pas mis le switch -d que la documentation dit de mettre - en le mettant, le problème disparaît), donc assez sûr pour moi. Dans les cas où il y a vraiment un problème, on peut toujours désactiver l'optimisation qui pose problème.

tu réponds à côté : je te reproche de prétendre vouloir optimiser les programmes en taille, alros que tes propres programmes (au moins ceux que j'ai vu) ne sont clairement aps une référence de ce point de vue-là

Pollux
: Et aussi que tu préfères la "validité" d'un programme à la taille qu'il prend (même si cette "validité" consiste à faire gagner 1 bit de seed pour prendre une 30aine d'octets en plus). Bizarrement, cette fois-ci c'est le contraire, alors que 99.000% est très inférieur à 99.994%

Tu compares des pourcentages qui ne sont pas comparables.

et que la place gagnée par les optimisations ASM ne doit jamais dépasser les 20 octets même sur le plus complexe des programmes

Relis les messages ci-dessus. J'ai gagné plusieurs KO sur CC rien qu'avec les optimisations du linker!

(sans compter que l'impact d'une collision de générateur aléatoire est quasi-nul, alors que celui d'un programme qui se comporte anormalement est très grave et fait perdre un temps précieux au programmeur).

Je vois ça autrement: les collisions (ou autres problèmes) causé(e)s par un mauvais générateur de nombres aléatoires sont inévitables. En exécutant le programme suffisamment de fois, on atteint forcément le cas "mauvais". En revanche, pour les programmes détruits par un optimisateur, il suffit de vérifier que le programme a été compilé correctement (par exemple en le testant, ou idéalement en comparant les sources avec ce que sort ttdasm) et puis il restera correct, qu'on l'exécute une fois ou des millions de fois. Une fois la correction vérifiée, on ne peut jamais produire l'erreur rien qu'en exécutant le programme, même si on passe toute sa vie à exécuter le programme en boucle. C'est donc un problème de nature totalement différente.

J'ai un peu l'impression que, comme SnowTiger, tu façonnes ton opinion de "The Right Thing" en fonction de ce que tu as dit avant et de ce qui te remettrait le moins en cause...

Je ne suis pas d'accord. Cf. l'explication ci-dessus.

et attention, je ne parle que des optimisations portant sur l'ASM, pas sur le code C

Dans ce cas, ton argumentation ne vaut rien. Actuellement, on a obligatoirement besoin des optimisations du linker aussi pour le C. GCC 3.4 pourra changer ça un peu (il permet de compiler plusieurs .c en même temps). Mais pas entièrement, parce qu'il y a aussi les librairies statiques, qui chez nous sont de vraies librairies statiques, pas des archives de sources.

Flanker
: tu réponds à côté : je te reproche de prétendre vouloir optimiser les programmes en taille, alros que tes propres programmes (au moins ceux que j'ai vu) ne sont clairement aps une référence de ce point de vue-là

Reproche très bizarre.
Mes programmes ASM sont mal optimisés parce qu'ils sont vieux et que je n'étais pas très bon en optimisation à l'époque. Je ne vais pas tout réécrire juste pour les optimiser. Ils marchent comme ils sont, donc ça serait vraiment perdre mon temps. Si je les écrivais maintenant, ils seraient certainement pas mal plus compacts. (Mais probablement toujours pas aussi compacts que les tiens, tu m'as l'air très doué en optimisation, toi. Et ce compliment est entièrement sérieux!)

Kevin, quitte à faire des réponses massives, s'il te plait, fait des réponses complètes à tout, pas seulement au arguments qui ne te dérangent pas.

Les morceaux que je coupe ne sont pas des arguments qui me dérangent, mais du remplissage qui n'apporte aucune information, et donc aucune réponse possible.

donc si je pige bien, un argument que tu :
-ne comprends pas
-désaprouve
-trouve inutile
sont du remplissage n'apportant aucune info ?

sans oublier :
- les questions embarassantes

Stop les accusations infondées. Je vous réinvite dès que vous présentez vos excuses par mini-message.

Kevin Kofler
:

Pollux
: Et aussi que tu préfères la "validité" d'un programme à la taille qu'il prend (même si cette "validité" consiste à faire gagner 1 bit de seed pour prendre une 30aine d'octets en plus). Bizarrement, cette fois-ci c'est le contraire, alors que 99.000% est très inférieur à 99.994%

Tu compares des pourcentages qui ne sont pas comparables.

Si, ce sont des taux d'erreur pour un gain d'une 20aine d'octets [en admettant que le gain ne soit que d'une 20aine d'octets, ce dont je parle plus bas]. Et même mieux : l'erreur est encore plus grave dans le cas de tes "optimisations".

et que la place gagnée par les optimisations ASM ne doit jamais dépasser les 20 octets même sur le plus complexe des programmes

Relis les messages ci-dessus. J'ai gagné plusieurs KO sur CC rien qu'avec les optimisations du linker!

Putain, Kevin! Ca t'arrive de lire les posts en entier? Mon post précédent excluait explicitement le cas des optimisations sur le code C : pour le code C, on est d'accord, tu fais ce que tu veux (et tu as parfaitement le droit de le faire dans le linker si ça te fait plaisir, ce n'est pas ça que je critique). Je dis que pour le code ASM, le rapport gain de place / taux d'erreur est plus faible que pour le remplacement de ta fonction randomize() "mathématiquement idéale" () par ma fonction.

(sans compter que l'impact d'une collision de générateur aléatoire est quasi-nul, alors que celui d'un programme qui se comporte anormalement est très grave et fait perdre un temps précieux au programmeur).

Je vois ça autrement: les collisions (ou autres problèmes) causé(e)s par un mauvais générateur de nombres aléatoires sont inévitables. En exécutant le programme suffisamment de fois, on atteint forcément le cas "mauvais".

Si tu te mets à parler d'inévitable, ça veut dire que tu fais des tests successifs; alors tu n'auras une collision qu'au bout de 2 milliards de tests (et pas 16000 en prenant des tests aléatoires).

En revanche, pour les programmes détruits par un optimisateur, il suffit de vérifier que le programme a été compilé correctement (par exemple en le testant, ou idéalement en comparant les sources avec ce que sort ttdasm) et puis il restera correct, qu'on l'exécute une fois ou des millions de fois. Une fois la correction vérifiée, on ne peut jamais produire l'erreur rien qu'en exécutant le programme, même si on passe toute sa vie à exécuter le programme en boucle. C'est donc un problème de nature totalement différente.

Sauf que _personne_ n'a _jamais_ fait la vérification avec ttdasm de son programme, et pour cause : si j'assemble un truc, je suppose que l'assembleur va faire son boulot et pas le modifier en faisant des suppositions trop fortes sur la signification de "bsr", par exemple. En plus, c'est pas du tout viable : le formattage est très différent (sans même parler des macros!), et ttdasm n'est pas parfait.

La seule méthode réellement employée, et ça tu ne peux pas le nier, c'est le débogage à la main. Ca veut dire que l'erreur peut se manifester une fois sur 50, ou bien seulement dans des cas particuliers (par exemple le bug de mon exemple de fonction de détection de ghost space pourrait ne foirer que si le programme avait déjà été appelé par un prog basic et que donc le programme n'a pas été rechargé par le TIOS, etc... : typiquement, c'est le genre de truc difficilement reproductible et donc difficilement testable). Et crois-moi, ça fait perdre un temps précieux. Et il suffit d' "upgrader" sa version de TIGCC pour introduire des nouveaux bugs, c'est ça le plus gênant

et attention, je ne parle que des optimisations portant sur l'ASM, pas sur le code C

Dans ce cas, ton argumentation ne vaut rien. Actuellement, on a obligatoirement besoin des optimisations du linker aussi pour le C. GCC 3.4 pourra changer ça un peu (il permet de compiler plusieurs .c en même temps). Mais pas entièrement

Ca, c'est un autre pb : si vous ne savez pas implémenter ça, tant pis. Mais tel que c'est implémenté, c'est complètement immonde, ça favorise les bugs, et je comprends qu'on veuille rester à TIGCC 0.94 si on veut utiliser plus d'une centaine de lignes de code ASM...

les librairies statiques, qui chez nous sont de vraies librairies statiques, pas des archives de sources.

Et vive les approximations foireuses ... Il y a bcp moins de différence entre le code intermédiaire et votre code objet avec tous les labels locaux qu'entre la source et le code intermédiaire...

<off-topic>

./129>

Kevin Kofler :
Je vous réinvite dès que vous présentez vos excuses par mini-message.

yAro, il faudrait ajouter une feature à yN : possibilité pour les admins d'enlever définitivement le droit de kick à certains utilisateurs...

</off-topic>

Tout à fait d'accord avec Pollux.
Kevin> tu sais qu'en les kickant tu leur donnes raison ?

D'accord avec Pollux aussi...




Je ne vois vraiment aucune raison de les faire taire tout les deux, ce qu'ils disent n'est pas franchement infondé. Genant, sans doute, mais là pour le coup ça fait pas une raison suffisante.

Kevin Kofler
: Stop les accusations infondées.

Infondées ? Ce n'est pas moi qui ai soigneusement évité de répondre à des questions du genre "Parce que tu trouves que GCC est un bon exemple ?"

Euh... J'allais réinviter vince et nitro là, mais Vertyos l'a déjà fait, donc bon.
Cela dit. je préfèrerais que Vertyos ne se mèle pas dans la décision qui je kicke de mes topics...

Kicks injustifiés, il est normal que les modérateurs s'en mêlent
Si tu ne veux pas que qui que ce soit modère tes topics à ta place, apprend à te maitriser .. et à répondre au question plutôt que de kicker ceux qui les posent.

Kevin Kofler :
Cela dit. je préfèrerais que Vertyos ne se mèle pas dans la décision qui je kicke de mes topics...

Pour citer directement ce qu'on m'avait répondu sur Ti-Gen, puisque ça ira plus vite :

Maintenant si tu te permet de critiquer ce que font les admins et modos ici ça va être le ban direct

donc :
1° kick injustifié
2° pas de contestations
merci, au plaisir.

Cela dit. je préfèrerais que Vertyos ne se mèle pas dans la décision qui je kicke de mes topics...

c'est toujours la meme histoire avec toi... je vous fais des trucs mais j'aimerais pas que vous me les fassiez...

et n' "oublie" pas non plus de répondre à mon post...

Pollux
:

Kevin Kofler
:

Pollux
:Et aussi que tu préfères la "validité" d'un programme à la taille qu'il prend (même si cette "validité" consiste à faire gagner 1 bit de seed pour prendre une 30aine d'octets en plus). Bizarrement, cette fois-ci c'est le contraire, alors que 99.000% est très inférieur à 99.994%

Tu compares des pourcentages qui ne sont pas comparables.

Si, ce sont des taux d'erreur pour un gain d'une 20aine d'octets [en admettant que le gain ne soit que d'une 20aine d'octets, ce dont je parle plus bas]. Et même mieux : l'erreur est encore plus grave dans le cas de tes "optimisations".

Désolé, je ne comprends pas du tout d'où tu sors ces chiffres. Si tu pouvais expliciter... Parce que les chiffres qui "tombent du ciel", je ne vois vraiment pas quoi y répondre.

et que la place gagnée par les optimisations ASM ne doit jamais dépasser les 20 octets même sur le plus complexe des programmes

Relis les messages ci-dessus. J'ai gagné plusieurs KO sur CC rien qu'avec les optimisations du linker!

Putain, Kevin! Ca t'arrive de lire les posts en entier? Mon post précédent excluait explicitement le cas des optimisations sur le code C

Cf. le dernier paragraphe de ma réponse d'avant: se limiter à l'assembleur n'a aucun sens pour les raisons déjà évoquées.

pour le code C, on est d'accord, tu fais ce que tu veux (et tu as parfaitement le droit de le faire dans le linker si ça te fait plaisir, ce n'est pas ça que je critique). Je dis que pour le code ASM, le rapport gain de place / taux d'erreur est plus faible que pour le remplacement de ta fonction randomize() "mathématiquement idéale" () par ma fonction.

Grave erreur. Je peux écrire un code ASM qui sera optimisable exactement autant que CC! C'est même trivial de le faire: tigcc -S *.c. Si on ne remarque pas les optimisations dans la plupart des programmes actuels en assembleur, c'est parce qu'ils ont été écrits pour des linkers débiles (parfois même pour des non-linkers qui ne prenaient qu'un seul fichier objet!) et utilisent donc des hacks affreux de style les include de code (comme déjà dit: à mort ce hack!). On peut tout à fait programmer proprement, c'est-à-dire en suivant les principes de la programmation modulaire (compilation séparée etc.) en assembleur, et là, on aura besoin des optimisations du linker pour que le style propre ait exactement la même efficacité que le style sale et obsolète. Un des grands points forts des optimisations du linker est d'encourager la programmation modulaire propre en éliminant totalement la pénalité de l'utilisation de plusieurs fichiers objet, rendant ainsi le hack des include de code totalement inutile et obsolète. Et c'est valable pour l'assembleur autant que pour le C.

(sans compter que l'impact d'une collision de générateur aléatoire est quasi-nul, alors que celui d'un programme qui se comporte anormalement est très grave et fait perdre un temps précieux au programmeur).

Je vois ça autrement: les collisions (ou autres problèmes) causé(e)s par un mauvais générateur de nombres aléatoires sont inévitables. En exécutant le programme suffisamment de fois, on atteint forcément le cas "mauvais".

Si tu te mets à parler d'inévitable, ça veut dire que tu fais des tests successifs; alors tu n'auras une collision qu'au bout de 2 milliards de tests (et pas 16000 en prenant des tests aléatoires).

Mon "million" était un chiffre au hasard (d'où l'écriture en lettres, pas en chiffres), et ici, j'ai même opté pour "suffisamment de fois" qui est encore plus clair. 2 milliards de fois, c'est un nombre fini d'essais, donc qualifie très bien comme "suffisamment de fois".

En revanche, pour les programmes détruits par un optimisateur, il suffit de vérifier que le programme a été compilé correctement (par exemple en le testant, ou idéalement en comparant les sources avec ce que sort ttdasm) et puis il restera correct, qu'on l'exécute une fois ou des millions de fois. Une fois la correction vérifiée, on ne peut jamais produire l'erreur rien qu'en exécutant le programme, même si on passe toute sa vie à exécuter le programme en boucle. C'est donc un problème de nature totalement différente.

Sauf que _personne_ n'a _jamais_ fait la vérification avec ttdasm de son programme,

Sauf moi.
C'est la meilleure manière de voir si la sortie correspond à l'entrée. Mais bon, j'avoue que je ne l'ai fait que pour des très petits programmes, et c'était souvent pour déboguer le linker.

et pour cause : si j'assemble un truc, je suppose que l'assembleur va faire son boulot et pas le modifier en faisant des suppositions trop fortes sur la signification de "bsr", par exemple. En plus, c'est pas du tout viable : le formattage est très différent (sans même parler des macros!), et ttdasm n'est pas parfait.

Le formattage différent n'a aucune importance, vu qu'il s'agit de comparer à la main, pas automatiquement.

La seule méthode réellement employée, et ça tu ne peux pas le nier, c'est le débogage à la main. Ca veut dire que l'erreur peut se manifester une fois sur 50, ou bien seulement dans des cas particuliers

Dans ces cas, tout dépend de la qualité des tests effectués. Avec un bon whiteboxing, on teste tous les chemins d'exécution. Mais comme déjà dit, l'idéal est de comparer avec ce que sort ttdasm.

(par exemple le bug de mon exemple de fonction de détection de ghost space pourrait ne foirer que si le programme avait déjà été appelé par un prog basic et que donc le programme n'a pas été rechargé par le TIOS, etc... : typiquement, c'est le genre de truc difficilement reproductible et donc difficilement testable). Et crois-moi, ça fait perdre un temps précieux.

Il est vrai que des fois les tests sont vraiment durs à faire. D'où mon conseil d'utiliser ttdasm.

Et d'ailleurs, pour le cas des problèmes avec l'optimisation tailcall des bsr, il suffit de regarder la source pour voir s'il y a un problème, on n'a même pas besoin de désassembler ou tester le résultat! C'est simple: S'il y a un bsr ou jsr label suivi d'un rts sans aucun label entre les 2, ça sera optimisé.

Et il suffit d' "upgrader" sa version de TIGCC pour introduire des nouveaux bugs, c'est ça le plus gênant

Non, il "suffit" de mettre à jour TIGCC et d'activer de nouvelles optimisations. Et il ne faut vraiment pas faire semblant de ne pas être au courant, vu que toutes mes annonces des bêtas parlent à chaque fois des nouvelles optimisations (dans les "rappels").

Actuellement, on a obligatoirement besoin des optimisations du linker aussi pour le C. GCC 3.4 pourra changer ça un peu (il permet de compiler plusieurs .c en même temps). Mais pas entièrement

Ca, c'est un autre pb : si vous ne savez pas implémenter ça, tant pis. Mais tel que c'est implémenté, c'est complètement immonde, ça favorise les bugs, et je comprends qu'on veuille rester à TIGCC 0.94 si on veut utiliser plus d'une centaine de lignes de code ASM...

Ben, moi, je ne comprends pas vraiment. Ce qui règne ici, c'est une grosse paranoia appuyée sur des exemples construits (pas tirés du monde réel) pour des cas totalement improbables, ainsi que sur des exemples réels (ceux de Flanker) qui ne boguent pas à cause d'une erreur fondamentale des optimisations du linker, mais à cause d'un problème de switches qui peut être résolu par l'utilisateur en RTFM et par les versions futures de TIGCC en mettant le bon switch automatiquement. Je répète: les exemples réels cités par Flanker ne sont pas des victimes inévitables des optimisations du linker! Toutes les victimes inévitables citées étaient des exemples construits spécialement pour ça (dont je connaissais déjà l'existance théorique), qui n'existent pas en pratique.

les librairies statiques, qui chez nous sont de vraies librairies statiques, pas des archives de sources.

Et vive les approximations foireuses ... Il y a bcp moins de différence entre le code intermédiaire et votre code objet avec tous les labels locaux qu'entre la source et le code intermédiaire...

Personnellement, je trouve que le mode all-relocs est le seul mode d'assemblage raisonnable. L'assembleur n'a pas à essayer de faire le travail du linker en supprimant les labels locaux et en prérésolvant les références PC-relatives locales. La résolution des relogements et la gestion des labels font partie du boulot du linker. Je trouve que ce n'est vraiment pas malin de mettre la résolution des relogements dans l'assembleur, ça ne fait que dupliquer le travail du linker. Si jamais j'écris un nouvel assembleur pour TIGCC, il n'utilisera que le mode all-relocs.

Et ceci complètement indépendemment du discours des optimisations du linker, même si c'est ce qui a motivé le mode all-relocs, parce qu'il est absolument nécessaire que le linker ait ces informations pour qu'il puisse optimiser correctement.

Je refuse de commenter les messages ./131 et ./132 autrement qu'en disant que je ne suis pas du tout d'accord. Quant au ./133, j'ai déjà dit: je préfèrerais que Vertyos ne se mèle pas de mes affaires.

nitro
:

Kevin Kofler
:Stop les accusations infondées.

Infondées ? Ce n'est pas moi qui ai soigneusement évité de répondre à des questions du genre "Parce que tu trouves que GCC est un bon exemple ?"

Je devrais répondre quoi? Tu as bien raison sur ce point. GCC est limite illisible, malheureusement.

Là, je pense n'avoir rien sauté.

Ximoon :
Kicks injustifiés, il est normal que les modérateurs s'en mêlent

Déjà, je ne trouve pas que mes kicks étaient injustifiés. C'étaient des accusations sans fondement réel. Je n'ai presque rien sauté en répondant dans ce topic!

Si tu ne veux pas que qui que ce soit modère tes topics à ta place, apprend à te maitriser .. et à répondre au question plutôt que de kicker ceux qui les posent.

Pourquoi devrais-je tolérer qu'on pollue mes topics avec des accusations comme ça?

Vertyos
:

Kevin Kofler :
Cela dit. je préfèrerais que Vertyos ne se mèle pas dans la décision qui je kicke de mes topics...

Pour citer directement ce qu'on m'avait répondu sur Ti-Gen, puisque ça ira plus vite :

Maintenant si tu te permet de critiquer ce que font les admins et modos ici ça va être le ban direct

donc :
1° kick injustifié
2° pas de contestations merci, au plaisir.

Tu t'amuses encore à faire le dictateur???
Sur Ti-Gen, c'était totalement différent: tu voulais continuer à faire ton dictateur, alors que tu savais très bien que tu n'étais qu'un simple visiteur (et maintenant même plus ça: tu es maintenant un simple visiteur banni ).
Et ne fais pas semblant de ne pas savoir pourquoi tu as été banni de Ti-Gen! Je peux quand-même te redonner la raison: Circonvention technique de mesures administratives (en clair: hacking) aggravée par insolence, provocation et non-respect total des règles du forum et de la netiquette.

sBibi
:

Cela dit. je préfèrerais que Vertyos ne se mèle pas dans la décision qui je kicke de mes topics...

c'est toujours la meme histoire avec toi... je vous fais des trucs mais j'aimerais pas que vous me les fassiez...

J'ai posté dans tes topics pour t'accuser de réponses sélectives qui "arrangent"??? Non! J'ai fait ça dans les topics de quelqu'un d'autre??? Non plus! Alors non, je ne vous fais pas les trucs que je n'aimerais pas que vous me fassiez.

Pollux
: et n' "oublie" pas non plus de répondre à mon post...

J'ai répondu à tout là, alors pour les accusations de réponses sélectives, c'est DVC.

Oh, et je rajouterai: Il m'arrive de répondre de manière séléctive, mais ce n'est pas du tout pour évader certaines questions ou certains arguments, mais pour une raison simple: répondre complètement à des messages longs comme ceux de Pollux ici prend du temps, temps que je n'ai pas toujours. Donc je suis parfois obligé de me limiter aux points les plus intéressants. Certe, le choix peut paraître subjectif, mais les contraintes de temps sont ce qu'elles sont.

Cela dit, comme déjà dit, tout ceci ne concerne pas vraiment ce topic.

tatata kevin, tu t'emportes là. et puis j'ai pas été "banni", j'ai été banni 8 fois
(bientot 9 d'ailleurs, g même plus à m'en occuper ça recréé tt seul..)

"J'ai posté dans tes topics pour t'accuser de réponses sélectives qui "arrangent"??? Non!"

toi par contre c'etait fonde maintenant plus forcement vu que t'as repondu, mais a la date de ces posts, ces accusations etaient fondees...

"Alors non, je ne vous fais pas les trucs que je n'aimerais pas que vous me fassiez."

t'as dit: "Maintenant si tu te permet de critiquer ce que font les admins et modos ici ça va être le ban direct"

or c'est ce que tu fais toi meme sans arret ici... donc en suivant ta logique, il faudrait te ban direct?

(dsl pour le topic, je sais j'y apporte rien en parlant de ca... c'est juste que c'est ton topic et que ce dont je parle a un rapport relativement lie a toi, donc c'est pas vraiment completement hors sujet non plus )

"Tu t'amuses encore à faire le dictateur???"

c'est toi qui dit ca? mais LOL

"Circonvention technique de mesures administratives (en clair: hacking)"

oue, c'est clair, c'est infiniment mieux de ne rien dire et de laisser les bugs non repares, comme ca quelqu'un de vraiment mal intentionne peut bien foutre la merde selon ce que c'est... super...

Vertyos :
tatata kevin, tu t'emportes là. et puis j'ai pas été "banni", j'ai été banni 8 fois

Ce que tu n'as toujours pas compris, c'est que sur Ti-Gen (comme sur le forum de la TICT d'ailleurs), "banni" veut dire vraiment "banni", pas "banni jusqu'à recréation du pseudo" comme ici. Donc il est évident que tous tes nouveaux pseudos seront supprimés à nouveau.

(bientot 9 d'ailleurs, g même plus à m'en occuper ça recréé tt seul..)

Bon sang, pourquoi ne peux-tu pas arrêter de nous faire ch**r??? Tu sais que tu es banni, pourquoi essayer de passer outre à chaque fois? Ne comprends-tu pas que tu ne fais qu'aggraver ton cas, et réduire à chaque fois la probabilité (déjà minime) d'être débanni un jour? Si tu veux rester banni de Ti-Gen jusqu'à ta mort, tu es sur la bonne voie.

sBibi :
"J'ai posté dans tes topics pour t'accuser de réponses sélectives qui "arrangent"??? Non!"

toi par contre c'etait fonde maintenant plus forcement vu que t'as repondu, mais a la date de ces posts, ces accusations etaient fondees...

Désolé, je ne suis pas du tout d'accord. J'ai répondu à pratiquement tout dans ce topic.

"Alors non, je ne vous fais pas les trucs que je n'aimerais pas que vous me fassiez."

t'as dit: "Maintenant si tu te permet de critiquer ce que font les admins et modos ici ça va être le ban direct"

or c'est ce que tu fais toi meme sans arret ici... donc en suivant ta logique, il faudrait te ban direct?

Il y a confusion ici: C'est geogeo qui a dit ça comme ça! Personnellement, ce qui m'a dérangé le plus n'est pas qu'il a critiqué notre travail, mais qu'il a utilisé une faille du forum pour poster dans les topics lockés.

(dsl pour le topic, je sais j'y apporte rien en parlant de ca... c'est juste que c'est ton topic et que ce dont je parle a un rapport relativement lie a toi, donc c'est pas vraiment completement hors sujet non plus )

Je trouve que c'est très hors-sujet. Mais bon...

Kevin Kofler :
J'ai répondu à tout là, alors pour les accusations de réponses sélectives, c'est DVC.

Maintenant tu peux peut-être passer dans le topic "Actu - Divers / Juste pour savoir" et répondre à "Encore une fois tu penses être le seul à avoir raison. Les autres c'est tous des sous-merdes, c'est ça ?". Je serais curieux de connaître la raison pour laquelle tous ceux qui ne pensent pas comme toi sont des incapables...

sBibi :
"Tu t'amuses encore à faire le dictateur???"

c'est toi qui dit ca? mais LOL

"Circonvention technique de mesures administratives (en clair: hacking)"
oue, c'est clair, c'est infiniment mieux de ne rien dire et de laisser les bugs non repares, comme ca quelqu'un de vraiment mal intentionne peut bien foutre la merde selon ce que c'est... super...

Tu n'as pas compris: Pour montrer le bogue, il suffit de le faire une fois! Lui, il a fait ça systématiquement (au moins 3 fois), alors que dès la première fois, j'ai remplacé son message par une remarque comme quoi ce qu'il faisait était interdit par les règles de Ti-Gen. Donc il savait très bien que ce qu'il faisait n'était pas OK, il l'a fait exprès pour faire ch**r!

nitro
:

Kevin Kofler :
J'ai répondu à tout là, alors pour les accusations de réponses sélectives, c'est DVC.

Maintenant tu peux peut-être passer dans le topic "Actu - Divers / Juste pour savoir" et répondre à "Encore une fois tu penses être le seul à avoir raison. Les autres c'est tous des sous-merdes, c'est ça ?". Je serais curieux de connaître la raison pour laquelle tous ceux qui ne pensent pas comme toi sont des incapables...

La réponse est simple: Je ne pense pas du tout ça! Alors la "raison pour laquelle je pense ça" n'existe évidemment pas.

Et d'ailleurs, je n'avais pas répondu parce que c'est une accusation tellement grossière et insolente (de plus qu'elle est totalement infondée) que je n'avais pas du tout envie d'y répondre.

Kevin Kofler
:

Pollux
:

Kevin Kofler
:

Pollux
: Et aussi que tu préfères la "validité" d'un programme à la taille qu'il prend (même si cette "validité" consiste à faire gagner 1 bit de seed pour prendre une 30aine d'octets en plus). Bizarrement, cette fois-ci c'est le contraire, alors que 99.000% est très inférieur à 99.994%

Tu compares des pourcentages qui ne sont pas comparables.

Si, ce sont des taux d'erreur pour un gain d'une 20aine d'octets [en admettant que le gain ne soit que d'une 20aine d'octets, ce dont je parle plus bas]. Et même mieux : l'erreur est encore plus grave dans le cas de tes "optimisations".

Désolé, je ne comprends pas du tout d'où tu sors ces chiffres. Si tu pouvais expliciter... Parce que les chiffres qui "tombent du ciel", je ne vois vraiment pas quoi y répondre.

Je détaille : ton 99% vient de toi et est censé être la proportion de progs ASM correctement compilés. Le 99.994% est la probabilité qu'il y n'ait pas la moindre collision dans la génération de 500 seeds différents avec un seed de 31 bits... Et l'ordre de grandeur est le même.

et que la place gagnée par les optimisations ASM ne doit jamais dépasser les 20 octets même sur le plus complexe des programmes

Relis les messages ci-dessus. J'ai gagné plusieurs KO sur CC rien qu'avec les optimisations du linker!

Putain, Kevin! Ca t'arrive de lire les posts en entier? Mon post précédent excluait explicitement le cas des optimisations sur le code C

Cf. le dernier paragraphe de ma réponse d'avant: se limiter à l'assembleur n'a aucun sens pour les raisons déjà évoquées.

Ce paragraphe-là n'explique rien, mais par contre le paragraphe suivant de ce post donne un semblant de raison...

pour le code C, on est d'accord, tu fais ce que tu veux (et tu as parfaitement le droit de le faire dans le linker si ça te fait plaisir, ce n'est pas ça que je critique). Je dis que pour le code ASM, le rapport gain de place / taux d'erreur est plus faible que pour le remplacement de ta fonction randomize() "mathématiquement idéale" () par ma fonction.

Grave erreur. Je peux écrire un code ASM qui sera optimisable exactement autant que CC! C'est même trivial de le faire: tigcc -S *.c.

Ce n'est pas une raison pour transformer les bsr/rts en bra, parce que ça change carrément la sémantique... Normalement, la sémantique de "tigcc *.s" devrait être la même que "cat *.s > $$.s && tigcc $$.s && rm -f $$.s" (modulo le nom du fichier de sortie, et modulo les éventuels conflits de macro). Et c'est largement faisable : sauf qu'il ne faut pas utiliser un format objet hacké dans tous les sens, il faut utiliser un code intermédiaire gardant toutes les infos sémantiques du fichier assembleur de départ...

Si on ne remarque pas les optimisations dans la plupart des programmes actuels en assembleur, c'est parce qu'ils ont été écrits pour des linkers débiles (parfois même pour des non-linkers qui ne prenaient qu'un seul fichier objet!) et utilisent donc des hacks affreux de style les include de code (comme déjà dit: à mort ce hack!). On peut tout à fait programmer proprement, c'est-à-dire en suivant les principes de la programmation modulaire (compilation séparée etc.) en assembleur, et là, on aura besoin des optimisations du linker pour que le style propre ait exactement la même efficacité que le style sale et obsolète. Un des grands points forts des optimisations du linker est d'encourager la programmation modulaire propre en éliminant totalement la pénalité de l'utilisation de plusieurs fichiers objet, rendant ainsi le hack des include de code totalement inutile et obsolète. Et c'est valable pour l'assembleur autant que pour le C.

(sans compter que l'impact d'une collision de générateur aléatoire est quasi-nul, alors que celui d'un programme qui se comporte anormalement est très grave et fait perdre un temps précieux au programmeur).

Je vois ça autrement: les collisions (ou autres problèmes) causé(e)s par un mauvais générateur de nombres aléatoires sont inévitables. En exécutant le programme suffisamment de fois, on atteint forcément le cas "mauvais".

Si tu te mets à parler d'inévitable, ça veut dire que tu fais des tests successifs; alors tu n'auras une collision qu'au bout de 2 milliards de tests (et pas 16000 en prenant des tests aléatoires).

Mon "million" était un chiffre au hasard (d'où l'écriture en lettres, pas en chiffres), et ici, j'ai même opté pour "suffisamment de fois" qui est encore plus clair. 2 milliards de fois, c'est un nombre fini d'essais, donc qualifie très bien comme "suffisamment de fois".

Qui parle de million?

En revanche, pour les programmes détruits par un optimisateur, il suffit de vérifier que le programme a été compilé correctement (par exemple en le testant, ou idéalement en comparant les sources avec ce que sort ttdasm) et puis il restera correct, qu'on l'exécute une fois ou des millions de fois. Une fois la correction vérifiée, on ne peut jamais produire l'erreur rien qu'en exécutant le programme, même si on passe toute sa vie à exécuter le programme en boucle. C'est donc un problème de nature totalement différente.

Sauf que _personne_ n'a _jamais_ fait la vérification avec ttdasm de son programme,

Sauf moi. C'est la meilleure manière de voir si la sortie correspond à l'entrée. Mais bon, j'avoue que je ne l'ai fait que pour des très petits programmes, et c'était souvent pour déboguer le linker.

Bah oui, en dehors de testcases simples, c'est complètement impraticable.

et pour cause : si j'assemble un truc, je suppose que l'assembleur va faire son boulot et pas le modifier en faisant des suppositions trop fortes sur la signification de "bsr", par exemple. En plus, c'est pas du tout viable : le formattage est très différent (sans même parler des macros!), et ttdasm n'est pas parfait.

Le formattage différent n'a aucune importance, vu qu'il s'agit de comparer à la main, pas automatiquement.

Donc en plus il faut le faire à chaque modification du fichier?

La seule méthode réellement employée, et ça tu ne peux pas le nier, c'est le débogage à la main. Ca veut dire que l'erreur peut se manifester une fois sur 50, ou bien seulement dans des cas particuliers

Dans ces cas, tout dépend de la qualité des tests effectués. Avec un bon whiteboxing, on teste tous les chemins d'exécution. Mais comme déjà dit, l'idéal est de comparer avec ce que sort ttdasm.

Bah dans les deux cas c'est gore, et tout sauf sûr.

(par exemple le bug de mon exemple de fonction de détection de ghost space pourrait ne foirer que si le programme avait déjà été appelé par un prog basic et que donc le programme n'a pas été rechargé par le TIOS, etc... : typiquement, c'est le genre de truc difficilement reproductible et donc difficilement testable). Et crois-moi, ça fait perdre un temps précieux.

Il est vrai que des fois les tests sont vraiment durs à faire. D'où mon conseil d'utiliser ttdasm.

Toujours aussi impraticable, ça n'a pas changé depuis les 3 paragraphes précédents

Et d'ailleurs, pour le cas des problèmes avec l'optimisation tailcall des bsr, il suffit de regarder la source pour voir s'il y a un problème, on n'a même pas besoin de désassembler ou tester le résultat! C'est simple: S'il y a un bsr ou jsr label suivi d'un rts sans aucun label entre les 2, ça sera optimisé.

Bah oui mais on n'a pas forcément toutes les optimisations en tête, et rien ne dit que tu ne vas pas en rajouter de nouvelles...

Et il suffit d' "upgrader" sa version de TIGCC pour introduire des nouveaux bugs, c'est ça le plus gênant

Non, il "suffit" de mettre à jour TIGCC et d'activer de nouvelles optimisations. Et il ne faut vraiment pas faire semblant de ne pas être au courant, vu que toutes mes annonces des bêtas parlent à chaque fois des nouvelles optimisations (dans les "rappels").

Sauf qu'en pratique on les active qd même, ces optimisations parce que sans, TIGCC génère du code très largement moins bon que GTC...

Actuellement, on a obligatoirement besoin des optimisations du linker aussi pour le C. GCC 3.4 pourra changer ça un peu (il permet de compiler plusieurs .c en même temps). Mais pas entièrement

Ca, c'est un autre pb : si vous ne savez pas implémenter ça, tant pis. Mais tel que c'est implémenté, c'est complètement immonde, ça favorise les bugs, et je comprends qu'on veuille rester à TIGCC 0.94 si on veut utiliser plus d'une centaine de lignes de code ASM...

Ben, moi, je ne comprends pas vraiment. Ce qui règne ici, c'est une grosse paranoia appuyée sur des exemples construits (pas tirés du monde réel) pour des cas totalement improbables, ainsi que sur des exemples réels (ceux de Flanker) qui ne boguent pas à cause d'une erreur fondamentale des optimisations du linker, mais à cause d'un problème de switches qui peut être résolu par l'utilisateur en RTFM et par les versions futures de TIGCC en mettant le bon switch automatiquement. Je répète: les exemples réels cités par Flanker ne sont pas des victimes inévitables des optimisations du linker! Toutes les victimes inévitables citées étaient des exemples construits spécialement pour ça (dont je connaissais déjà l'existance théorique), qui n'existent pas en pratique.

Ca, ça m'étonnerait énormément...

les librairies statiques, qui chez nous sont de vraies librairies statiques, pas des archives de sources.

Et vive les approximations foireuses ... Il y a bcp moins de différence entre le code intermédiaire et votre code objet avec tous les labels locaux qu'entre la source et le code intermédiaire...

Personnellement, je trouve que le mode all-relocs est le seul mode d'assemblage raisonnable. L'assembleur n'a pas à essayer de faire le travail du linker en supprimant les labels locaux et en prérésolvant les références PC-relatives locales. La résolution des relogements et la gestion des labels font partie du boulot du linker. Je trouve que ce n'est vraiment pas malin de mettre la résolution des relogements dans l'assembleur, ça ne fait que dupliquer le travail du linker. Si jamais j'écris un nouvel assembleur pour TIGCC, il n'utilisera que le mode all-relocs.

Le code objet n'est pas fait pour voir sa taille modifiée, il ne contient pas assez d'infos pour ça (même avec les labels locaux). La solution propre, c'est de prendre un code intermédiaire plus puissant que le code objet.

EDIT : oublié un [/ cite]