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