TIGCC 0.95 Beta 6 - Page 4

Kevin Kofler :
isinghostspace
bsr \chkghost
\dummy:
rts
\chkghost:
moveq #4,d0
and.w (a7),d0
rts

Argl, vous gérez les labels non utilisés comme les labels utilisés Ca supprime encore une bonne partie des possibilités d'optimisation...

Autre solution:
isinghostspace
dc.w $6102
rts
\chkghost:
moveq #4,d0
and.w (a7),d0
rts
Le linker ne fait l'optimisation tailcall que s'il y a un relogement (PC-relatif) (pour éviter de trafiquer des données), donc en codant le saut en dur, on évite l'optimisation. Mais je préfère la solution du label dummy.

... et ça marchera jusqu'à la version 0.98 qui, elle, supposera que les "dc.w" ne sont pas exécutables, pour les mettre dans une section séparée
C'est vraiment n'importe quoi, on ne sait pas quelles suppositions on peut faire sans casser la prochaine version...

Je ne parle même pas du cas du code automodifiant

Hack grossier à éviter au maximum, et ce n'est pas étonnant si ça crée des problèmes avec l'optimisation. La solution la plus propre est de ne pas en utiliser.

Il n'y a pas à avoir d'optimisation, surtout

Si je veux faire du pseudo-assembleur et que je m'engage à respecter une sémantique plus forte que celle de l'assembleur pur (par exemple lorsque j'écris foo.w j'accepte que la partie haute du registre soit détruite; ou encore je m'engage à ne pas utiliser l'adresse de retour d'une fonction ailleurs que pour faire un rts), alors libre à moi d'utiliser un langage de programmation bas niveau qui serait une sorte d' "assembleur optimisé" (mais il faut bien être conscient que certains bouts de code ne pourront pas être aussi bien optimisés, paradoxalement, dans l'assembleur "optimisé" que dans l'assembleur pur : cf mes deux exemples) ; mais je n'ai aucune envie que le linker s'amuse à faire sa cuisine et modifie mon code assembleur pour pallier les incapacités du compilateur C...

Alors tu assembles à optimisations désactivées. Tu es libre de le faire. PpHd désactive même les optimisations de A68k, qui sont nettement moins dangereuses (switch -n).

... et dans ce cas-là TIGCC devient incapable de faire du bon code

Et puis on a aussi les optimisations des relogements, dont tu auras besoin au plus tard le jour où tu gèreras les vraies librairies statiques.

Tu me cherches, là Seule l'exportation de librairie statique n'est pas encore implémentée; l'importation, elle, marche depuis lgtps Et le nouveau générateur de code utilisera les libs statiques comme des libs de code intermédiaire, pas comme des libs de code objet, donc les optimisations seront largement plus poussées qu'avec des optimisations côté linker...

Justement, je te parle de vraies librairies statiques. Pas de librairies de code source. Si on a un fichier .a sans le code source, on ne peut pas l'utiliser avec ta méthode.

Et tu le génères à partir de quoi, le .a, à ton avis?

Kevin Kofler
: Et je rajouterai que si nous activons les optimisations même pour le code assembleur, c'est parce que les optimisations de relogements sont en général bienvenues même en assembleur. L'assembleur ne peut pas savoir si une référence (par exemple un saut) vers un fichier d'objet externe tiendra en 32 KO, voire en 128 octets. Le linker, lui, le sait, et peut choisir le saut le plus compact (et en même temps le plus rapide) possible en conséquence.

Sauf si on assemble au dernier moment, ce qui est largement plus propre que de modifier a posteriori un code dont on ne sait pas s'il provient d'instructions C, ASM, de données, s'il est destiné à mettre modifé ou pas, etc...

C'est d'ailleurs à peu près la seule optimisation que je trouve bienvenue, du moment qu'elle n'a pas lieu quand on spécifie la taille

Flanker :
du moment qu'elle n'a pas lieu quand on spécifie la taille

ah bon?

Pollux
:

Autre solution:
isinghostspace
dc.w $6102
rts
\chkghost:
moveq #4,d0
and.w (a7),d0
rts
Le linker ne fait l'optimisation tailcall que s'il y a un relogement (PC-relatif) (pour éviter de trafiquer des données), donc en codant le saut en dur, on évite l'optimisation. Mais je préfère la solution du label dummy.

... et ça marchera jusqu'à la version 0.98 qui, elle, supposera que les "dc.w" ne sont pas exécutables, pour les mettre dans une section séparée

C'est vraiment n'importe quoi, on ne sait pas quelles suppositions on peut faire sans casser la prochaine version...

Encore une fois, rien ne t'empêche de désactiver les optimisations si elles te dérangent.

Je ne parle même pas du cas du code automodifiant

Hack grossier à éviter au maximum, et ce n'est pas étonnant si ça crée des problèmes avec l'optimisation. La solution la plus propre est de ne pas en utiliser.

Il n'y a pas à avoir d'optimisation, surtout

Cf. ci-dessus.

Alors tu assembles à optimisations désactivées. Tu es libre de le faire. PpHd désactive même les optimisations de A68k, qui sont nettement moins dangereuses (switch -n).

... et dans ce cas-là TIGCC devient incapable de faire du bon code

N'importe quoi. Si tu programmes en assembleur, surtout à optimisations désactivées, c'est évidemment à toi de donner le code optimal. Et sur du code C, nos optimisations fonctionnent très bien.

Justement, je te parle de vraies
librairies statiques. Pas de librairies de code source. Si on a un fichier .a sans le code source, on ne peut pas l'utiliser avec ta méthode.

Et tu le génères à partir de quoi, le .a, à ton avis?

Mais tu n'es pas forcément l'auteur du fichier .a! Je te parle d'utiliser des librairies statiques d'auteurs tiers, moi! C'est le cas le plus fréquent, parce que c'est à ça que servent les librairies. (Bon, c'est quand-même mieux si l'auteur met la source, mais tu fais quoi s'il ne l'a pas mise?`)

Pollux
:

Kevin Kofler
: Et je rajouterai que si nous activons les optimisations même pour le code assembleur, c'est parce que les optimisations de relogements sont en général bienvenues même en assembleur. L'assembleur ne peut pas savoir si une référence (par exemple un saut) vers un fichier d'objet externe tiendra en 32 KO, voire en 128 octets. Le linker, lui, le sait, et peut choisir le saut le plus compact (et en même temps le plus rapide) possible en conséquence.

Sauf si on assemble au dernier moment, ce qui est largement plus propre que de modifier a posteriori un code dont on ne sait pas s'il provient d'instructions C, ASM, de données, s'il est destiné à mettre modifé ou pas, etc...

Le linker sait faire la différence entre code et données à travers plusieurs mécanismes qui marchent à coup presque sûr:
* sections marquées "de données" (pas d'optimisation dans des sections de données)
* présence ou absence de relogements (pas d'optimisation sans relogements)
* inhibition des optimisations en cas de séquences (tailcalls par exemple) interrompues par un label
et les versions futures de TIGCC sont susceptibles d'améliorer encore la communication entre assembleur(s) et linker pour réduire le risque d'"optimiser" des données. (Il y a déjà pas mal de patches dans nos 2 assembleurs pour gérer au mieux l'optimisation dans le linker.)

Flanker :
C'est d'ailleurs à peu près la seule optimisation que je trouve bienvenue, du moment qu'elle n'a pas lieu quand on spécifie la taille

Désolé, le linker n'a (actuellement) aucun moyen de savoir si tu as spécifié une taille ou non, donc il optimise toujours.

Et pour ma suggestion?

Kevin Kofler :
J'ai une idée: Je vais suggérer à Sebastian de passer automatiquement -d à A68k quand l'optimisation des bsr est activée, et ceci à la fois dans l'IDE et dans tigcc.exe. Ça devrait résoudre le problème une fois pour toutes.

C'est le dernier rappel. Soit les intéressés me répondent que la solution leur va (en relisant les explications qui détaillent pourquoi ça résout leur "bogue"), soit tout reste comme c'est. C'est votre dernière chance d'avoir le changement que vous demandez. J'en ai marre de lire des pages et des pages de discussions stupides, et aucune réponse envers une vraie solution.

Alors, vous la voulez, oui ou non? Rappel:
* oui = votre "bogue" est corrigé
* non = tout reste comme c'est actuellement, je ne ferai pas de suggestions alternatives (en particulier, la suppression complète de l'optimisation tailcall est hors de question, donc inutile de demander ça)

PS: Toute réponse "non" est non-constructive et entraînera automatiquement le kick du topic. (Raison: Si ne voulez pas de changement, alors inutile d'en discuter.)

:/
Moi je dis oui. On a avancé.
Mais le "bug" va réapparaître quand on assemblera en appelant directement A68k (càd sans passer par tiggcc.exe) ?
Il n'est pas possible de corriger a68k pour qu'il active lui-même -d quand on lui demande d'optimiser les bsr ?

Bon, je bosse en ce moment sur ld-tigcc pour y rajouter le support du TIB.
Le code d'export est terminé, il ne reste plus qu'à intégrer ça dans ld-tigcc pour qu'il l'utilise vraiment, sorte un fichier
d'extension .tib et pas autre chose, et voir quel symbole il faudra lui transmettre pour lier en TIB.

Mais tu n'es pas forcément l'auteur du fichier .a! Je te parle d'utiliser des librairies statiques d'auteurs tiers, moi! C'est le cas le plus fréquent, parce que c'est à ça que servent les librairies. (Bon, c'est quand-même mieux si l'auteur met la source, mais tu fais quoi s'il ne l'a pas mise?`)

au hasard : si y'a pas la source tu lances un troll sur le vaporware de ceux qui releasent des bêtas privées et tu poursuis avec les saintes écritures GPL...

Kevin Kofler
:

C'est vraiment n'importe quoi, on ne sait pas quelles suppositions on peut faire sans casser la prochaine version...

Encore une fois, rien ne t'empêche de désactiver les optimisations si elles te dérangent.

D'accord... Donc tu recommandes à ceux qui programment en assembleur de désactiver les optimisations du linker ? Comme quoi, ces fameuses optimisations sont vraiment une avancée majeure

Alors tu assembles à optimisations désactivées. Tu es libre de le faire. PpHd désactive même les optimisations de A68k, qui sont nettement moins dangereuses (switch -n).

... et dans ce cas-là TIGCC devient incapable de faire du bon code

N'importe quoi. Si tu programmes en assembleur, surtout à optimisations désactivées, c'est évidemment à toi de donner le code optimal. Et sur du code C, nos optimisations fonctionnent très bien.[/cite]
Oui, mais soit on active les optimisations du linker, soit on ne les active pas... Même si j'ai 2 ko de code ASM et 40 ko de code C, je suis qd même obligé de les désactiver...

Justement, je te parle de vraies
librairies statiques. Pas de librairies de code source. Si on a un fichier .a sans le code source, on ne peut pas l'utiliser avec ta méthode.

Et tu le génères à partir de quoi, le .a, à ton avis?

Mais tu n'es pas forcément l'auteur du fichier .a! Je te parle d'utiliser des librairies statiques d'auteurs tiers, moi! C'est le cas le plus fréquent, parce que c'est à ça que servent les librairies. (Bon, c'est quand-même mieux si l'auteur met la source, mais tu fais quoi s'il ne l'a pas mise?`)

Je réitère ma question : l'auteur tiers le génère à partir de quoi le .a, à ton avis? Le compilateur qui génère le .a a qd même plus que du code objet à sa disposition...

Flanker :
C'est d'ailleurs à peu près la seule optimisation que je trouve bienvenue, du moment qu'elle n'a pas lieu quand on spécifie la taille

Désolé, le linker n'a (actuellement) aucun moyen de savoir si tu as spécifié une taille ou non, donc il optimise toujours.

C'est bien ce qui me semblait : toutes vos optimisations sont unsafe

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%
tu te bats pour gagner quelques octets, alors que les rares exemples de tes programmes que j'ai regardé sont loin d'être à quelques octets près

Flanker :
on ajoute : tu te bats contre le close source, et tu t'en sers comme argument ultime contre GTC

(argument qui ne tient pas du tout la route puisque le code source ne sera pas nécessaire [sauf pour compiler ])

Kevin Kofler :
Le linker sait faire la différence entre code et données à travers plusieurs mécanismes qui marchent à coup presque sûr

Donc c'est du bidouillage, pur et simple.

Une meilleure idée (celle qu'à suggeré Pollux) est de déferer la génération de code au linker, qui pourrait, avant ça, effectuer des optimisations globales sur l'IR, puis générer l'assembleur, ou le code machine machine directement. Cette approche a déjà été experimentée par plusieurs chercheurs, notament sur un compilateur Modula 2 si je me souviens bien, et ça marche très bien. (cf. articles sur http://www.citeseer.com)

Je l'ai déjà dit N fois avec N grand, hein...

Kevin> Pour ton optimisation, je suis plutôt contre, parce que tu utilises un switch qui n'a rien à voir avec vos saletés. En outre, ça risque de ralentir l'édition des liens (enfin, ça reste peu important).
Personnellement, je suis plus que contre ce genre d'optimisations qui, comme l'a souligné Pollux, n'ont vraiment pas leur place dans le linker.
Dorénavant, je les désactiverai par défaut, et je trouve que TIGCC devrait en faire autant, il faudrait qu'elles ne soient activées que si l'utilisateur le demande explicitement.

Sasume :
Kevin> Pour ton optimisation, je suis plutôt contre, parce que tu utilises un switch qui n'a rien à voir avec vos saletés. En outre, ça risque de ralentir l'édition des liens (enfin, ça reste peu important).
Personnellement, je suis plus que contre ce genre d'optimisations qui, comme l'a souligné Pollux, n'ont vraiment pas leur place dans le linker. Dorénavant, je les désactiverai par défaut, et je trouve que TIGCC devrait en faire autant, il faudrait qu'elles ne soient activées que si l'utilisateur le demande explicitement.

Comme toutes les optimisations...

Ben pas les optimisations sûres.

quand tu utiliser GCC sous linux, ou VisualC sous windows, par défaut il te met des optimisations ?

ben pas chez moi, pourtant leur optimisations sont surement plus sur que celles du linker de TIGCC.

...or

C'est bien ce qui me semblait : toutes vos optimisations sont unsafe

donc

Comme toutes les optimisations...

pour aider a comprendre a quoi je répondait exactement :

Godzil
:

Sasume :
Kevin> Pour ton optimisation, je suis plutôt contre, parce que tu utilises un switch qui n'a rien à voir avec vos saletés. En outre, ça risque de ralentir l'édition des liens (enfin, ça reste peu important).
Personnellement, je suis plus que contre ce genre d'optimisations qui, comme l'a souligné Pollux, n'ont vraiment pas leur place dans le linker.
Dorénavant, je les désactiverai par défaut, et je trouve que TIGCC devrait en faire autant, il faudrait qu'elles (les optimisations) ne soient activées que si l'utilisateur le demande explicitement.

Comme toutes les optimisations...

Godzil :
quand tu utiliser GCC sous linux, ou VisualC sous windows, par défaut il te met des optimisations ?
ben pas chez moi, pourtant leur optimisations sont surement plus sur que celles du linker de TIGCC.

Non, ça n'a pas grand chose à voir : c'est parce que c'est légèrement plus rapide à compiler, et c'est surtout pour permettre le debugging (typiquement, tu commences _d'abord_ par débugger ton programme avant de le distribuer )
Ici, il n'y a pas de debugging, et la différence de taille (pour GCC) entre un prog optimisé et non optimisé peut être suffisamment grande pour que le prog ne tienne plus en 64ko. Et dans le cas de GTC, les optimisations sont tjs activées (mais elles prennent une faible part du temps de compilation, en tout cas avec le générateur de code actuel). A vrai dire, je me demande même si le temps d'assemblage gagné ne compense pas le temps passé à optimiser le code

Albert Instinct :
:/ Moi je dis oui. On a avancé.

OK.

Mais le "bug" va réapparaître quand on assemblera en appelant directement A68k (càd sans passer par tiggcc.exe) ?

Déjà appeler directement A68k n'est pas officiellement supporté, la méthode correcte est tigcc -c. Mais tu auras le même problème: il faut passer -WA,-d. C'est inévitable, parce que:

Il n'est pas possible de corriger a68k pour qu'il active lui-même -d quand on lui demande d'optimiser les bsr ?

... c'est le linker qui fait l'optimisation, pas l'assembleur. Comment veux-tu que A68k sache ce que tu veux mettre comme optimisations en linkant si tu fais le linking séparément? Donc non, ce n'est pas possible. La seule exception est la création de librairies statiques avec tigcc -ar ou l'équivalent dans l'IDE, qui devra aussi utiliser -d automatiquement (de même qu'elle utilise aussi toujours le mode all-relocs, parce qu'on ne sait pas en créant la librairie si le range-cutting sera activé lors du linking ou non).

Et je précise que je n'ai pas vraiment envie de changer le comportement par défaut de A68k pour des raisons de compatibilité.

Jean-Mouloud :
Bon, je bosse en ce moment sur ld-tigcc pour y rajouter le support du TIB.
Le code d'export est terminé, il ne reste plus qu'à intégrer ça dans ld-tigcc pour qu'il l'utilise vraiment, sorte un fichier d'extension .tib et pas autre chose, et voir quel symbole il faudra lui transmettre pour lier en TIB.

Cool.

Pollux
:

Kevin Kofler
:

C'est vraiment n'importe quoi, on ne sait pas quelles suppositions on peut faire sans casser la prochaine version...

Encore une fois, rien ne t'empêche de désactiver les optimisations si elles te dérangent.

D'accord... Donc tu recommandes à ceux qui programment en assembleur de désactiver les optimisations du linker ? Comme quoi, ces fameuses optimisations sont vraiment une avancée majeure

Personnellement, je compile mes programmes en assembleur à optimisations du linker activées et je n'ai jamais eu un problème.
Et ces optimisations sont une avancée surtout pour les fichiers en plusieurs modules, c'est-à-dire les programmes modulaires (propres) et/ou qui utilisent intensivement tigcc.a. C'est surtout le cas pour les programmes en C. Même si ça peut aussi servir pour certains programmes en assembleur. (On pourrait par exemple compiler DB92 proprement en plusieurs fichiers ASM séparés au lieu de tout mettre dans un seul avec include. À mort le hack des include de code.)

N'importe quoi. Si tu programmes en assembleur, surtout à optimisations désactivées, c'est évidemment à toi de donner le code optimal. Et sur du code C, nos optimisations fonctionnent très bien.

Oui, mais soit on active les optimisations du linker, soit on ne les active pas... Même si j'ai 2 ko de code ASM et 40 ko de code C, je suis qd même obligé de les désactiver...

Si ton code assembleur est propre, tu n'as aucun problème. Mes programmes assembleur sont compilables sans problèmes avec toutes les optimisations.

Mais tu n'es pas forcément l'auteur du fichier .a! Je te parle d'utiliser des librairies statiques d'auteurs tiers, moi! C'est le cas le plus fréquent, parce que c'est à ça que servent les librairies. (Bon, c'est quand-même mieux si l'auteur met la source, mais tu fais quoi s'il ne l'a pas mise?`)

Je réitère ma question : l'auteur tiers le génère à partir de quoi le .a, à ton avis? Le compilateur qui génère le .a a qd même plus que du code objet à sa disposition...

Mais ce que je veux dire est que les fichiers .a générés avec TIGCC (c'est-à-dire 99,9% des fichiers .a) seront inutilisables avec ton compilateur.

Désolé, le linker n'a (actuellement) aucun moyen de savoir si tu as spécifié une taille ou non, donc il optimise toujours.

C'est bien ce qui me semblait : toutes vos optimisations sont unsafe

Ce n'est pas unsafe. Qu'il y ait un bra.w ou un bra.s ne change strictement rien au sens du code. (Rappel: Les sauts PC-relatifs sont ajustés. C'est à ça que sert le mode all-relocs que j'ai rajouté aux 2 assembleurs.)

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 te bats pour gagner quelques octets, alors que les rares exemples de tes programmes que j'ai regardé sont loin d'être à quelques octets près

Dans les optimisations du linker, il ne s'agit pas d'octets, mais de kilo-octets! À titre d'exemple, CC (le compilateur on-calc) a gagné plusieurs KO avec les optimisations du linker (et d'autres encore avec BSS, relogements personnalisés etc.)! (Il faut d'ailleurs que je sorte la version recompilée. Mais bon, c'est facile à recompiler soi-mêmes à l'aide de la source fournie. Vous verrez bien la différence entre les optimisations activées et désactivées!)

nitro
:

Kevin Kofler :
Le linker sait faire la différence entre code et données à travers plusieurs mécanismes qui marchent à coup presque sûr

Donc c'est du bidouillage, pur et simple.

Mais du "bidouillage" qui a le mérite de fonctionner très bien, et d'être le point fort de TIGCC 0.95, donc désolé les puristes, mais on ne peut plus revenir en arrière. Les mécontents qui postent ici se comptent sur les doigts d'une main (ou presque), et en plus Pollux et Thibaut s'associent systématiquement à toute critique de TIGCC, justifiée ou non. Les gens qui nous ont remercié pour les nouvelles optimisations et les excellents résultats qu'ils donnent, eux, se comptent en dizaines.

Une meilleure idée (celle qu'à suggeré Pollux) est de déferer la génération de code au linker, qui pourrait, avant ça, effectuer des optimisations globales sur l'IR, puis générer l'assembleur, ou le code machine machine directement. Cette approche a déjà été experimentée par plusieurs chercheurs, notament sur un compilateur Modula 2 si je me souviens bien, et ça marche très bien. (cf. articles sur http://www.citeseer.com)

Comme ça? http://llvm.cs.uiuc.edu/
Mais ça n'apparaîtra pas dans TIGCC 0.95 ou 0.96. Au plus tôt dans la 0.97, si c'est utilisable dans TIGCC (ce qui n'est pas sûr).

Sasume
: Kevin> Pour ton optimisation, je suis plutôt contre, parce que tu utilises un switch qui n'a rien à voir avec vos saletés.

C'est un switch qui dit à l'assembleur de ne pas cacher ses symboles au linker. Pour pouvoir optimiser convenablement, notre linker travaille en partant du principe que l'assembleur lui dit la vérité. S'il lui cache ses labels, le linker a du mal à travailler. Donc voilà le rapport.

En outre, ça risque de ralentir l'édition des liens (enfin, ça reste peu important).

Peu importe, les optimisations la ralentissent beaucoup plus. Et le mode all-relocs nécessaire pour le range-cutting introduit aussi au moins autant d'informations dans le fichier objet que le switch -d. Et puis l'équivalent GNU as de -d est --keep-locals, qui est automatiquement activé en mode all-relocs (on n'a pas le choix: contrairement au format AmigaOS, le format COFF ne nous permet pas d'émettre les relogements qu'il nous faut sans émettre les labels correspondants), qui lui-même est activé automatiquement par le range-cutting (parce que le linker a besoin de connaître les références PC-relatives pour pouvoir réduire la taille d'un morceau de code au plein milieu d'un programme).

Personnellement, je suis plus que contre ce genre d'optimisations qui, comme l'a souligné Pollux, n'ont vraiment pas leur place dans le linker. Dorénavant, je les désactiverai par défaut, et je trouve que TIGCC devrait en faire autant, il faudrait qu'elles ne soient activées que si l'utilisateur le demande explicitement.

En ligne de commandes, c'est le cas, mais bon, le défaut en ligne de commandes est aussi -O0, donc... L'IDE, elle, cherche à mettre des règlages par défaut plus raisonnables, et donc -Os et optimisations du linker activées. Mais tout est personnalisable.

Godzil
: quand tu utiliser GCC sous linux, ou VisualC sous windows, par défaut il te met des optimisations ?

Cf. ci-dessus.

Ce n'est pas unsafe. Qu'il y ait un bra.w ou un bra.s ne change strictement rien au sens du code. (Rappel: Les sauts PC-relatifs sont ajustés. C'est à ça que sert le mode all-relocs que j'ai rajouté aux 2 assembleurs.)

et quand on a besoin de fixer la taille du code ? au hasard pour le début du standard nostub ? mais ce n'est qu'un exemple ...

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.

comment tu peux dire que c'est spur à au moins 99% ? tu as fait un calcul sur tous les programmes compilables possibles ? et tu n'est pas obligé de t'apercevoir du bug immédiatement, il faut toujours désactiver l'optimisation pour avoir un programme sûr à 100 %

Kevin, il faut que je retrouve la fois où tu m'avais emmerdé parceque je faisais un truc qui avait une probabilité de planter 1 fois sur 9999999... au nom de la "rigueur scientifique" tu avais gueulé que c'était inacceptable...
Tu te souviens ?

Flanker
:

Ce n'est pas unsafe. Qu'il y ait un bra.w ou un bra.s ne change strictement rien au sens du code. (Rappel: Les sauts PC-relatifs sont ajustés. C'est à ça que sert le mode all-relocs que j'ai rajouté aux 2 assembleurs.)

et quand on a besoin de fixer la taille du code ? au hasard pour le début du standard nostub ? mais ce n'est qu'un exemple ...

La section de démarrage des commentaires _nostub est marquée comme une section de données exactement à cause de ça. Le linker n'optimise pas les sections de données, et comme c'est une section de démarrage, la section de données se trouvera toujours dans le programme principal et pas dans un éventuel fichier de données externe. Tu vois, nous avons pensé à tout.

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.

comment tu peux dire que c'est spur à au moins 99% ? tu as fait un calcul sur tous les programmes compilables possibles ?

C'est une estimation subjective, mais à mon avis réaliste. Il faut vraiment que le programme soit très tordu ou qu'on manque énormément de chance pour qu'il y ait un problème.

et tu n'est pas obligé de t'apercevoir du bug immédiatement, il faut toujours désactiver l'optimisation pour avoir un programme sûr à 100 %

Si tu es parano à ce point, ttdasm est ton ami.

Albert Instinct :
Kevin, il faut que je retrouve la fois où tu m'avais emmerdé parceque je faisais un truc qui avait une probabilité de planter 1 fois sur 9999999... au nom de la "rigueur scientifique" tu avais gueulé que c'était inacceptable... Tu te souviens ?

Nos optimisations ne causent pas de bogues aléatoires! Si le programme est optimisé correctement, il restera correct même si on l'exécute un million de fois.

Tiens, je me souviens aussi du générateur aléatoire pour qui 31 bits de seed étaient une précision "inacceptable" pour un jeu... (sachant qu'une collision arrive en moyenne au bout de 16000 essais )

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% 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 (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).

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


(et attention, je ne parle que des optimisations portant sur l'ASM, pas sur le code C : ton attaque portait sur le fait que GTC ne fait pas ces optimisations ASM [puisque GTC fait les optimisations pour le C], donc je n'étudie que ce point-là, du point de vue des risques comme du point de vue de la place gagnée)

Kevin Kofler
:

Albert Instinct :
Kevin, il faut que je retrouve la fois où tu m'avais emmerdé parceque je faisais un truc qui avait une probabilité de planter 1 fois sur 9999999... au nom de la "rigueur scientifique" tu avais gueulé que c'était inacceptable... Tu te souviens ?

Nos optimisations ne causent pas de bogues aléatoires! Si le programme est optimisé correctement, il restera correct même si on l'exécute un million de fois.

hum...
Je sais pas ce que pensent les autres de ta réponse...