TIGCC 0.95 Beta 5 - Page 9

boaf, je trouve ca assez drole moi, en tt cas ca me fait sourire

Flanker :
J'ai l'impression qu'il y a un bug dans l'assembleur :
voici le code original
_te_undelete_selection:
btst.b #5,33(a3);on regarde si la sélection est activée
beq _te_undelete_selection_exit
.....
bsr _sto_block
_te_undelete_selection_exit:
rts

il est assemblé en

_te_undelete_selection:
btst.b #5,33(a3);on regarde si la sélection est activée
beq _te_undelete_selection_exit
.....
bra _sto_block
_te_undelete_selection_exit:

c'est un peu gênant, non ?

Il faut assembler avec le switch -d pour que le label soit reconnu par le linker. Sinon, le linker va en effet faire cette optimisation non valide dans ce cas (optimisation tailcall).

En plus, je vois carrément pas ce que cette optimisation vient faire dans le linker

Pollux :
En plus, je vois carrément pas ce que cette optimisation vient faire dans le linker

GCC la rate parfois, donc il faut bien qu'on la fasse quelque part.
Et au départ, on pensait aussi appliquer ça pour le code de démarrage (là où on colle 2 sections). Mais depuis, avec la vérification de présence d'un label entre les 2, je pense que le tailcall ne sera plus optimisé si les 2 instructions proviennent de 2 sections différentes.

Et d'ailleurs, pour le switch -d à mettre, c'est dans la documentation. http://tigcc.ticalc.org/doc/ld.html#bincode_return. Et l'IDE le met par défaut pour les nouveaux projets.

Kevin Kofler
:

Pollux :
En plus, je vois carrément pas ce que cette optimisation vient faire dans le linker

GCC la rate parfois, donc il faut bien qu'on la fasse quelque part.

Oui, c'est pour ça que ""... Qu'est-ce qui empêcherait de le faire dans GCC ? (surtout qu'il n'y a pas de difficulté liée aux labels, puisque le linker non plus ne peut rien faire dans ce cas)

Ce bug sera-t-il corrigé ?

Non. Ce n'est pas un bogue. C'est le comportement voulu. Mets le switch -d comme dit dans la doc.

N'empêche que ça n'a rien à faire dans le linker, et que ça doit demander une ligne de plus à changer...

C'est une optimisation utile et volontairement présente, il y a écrit noir sur blanc comment éviter des problèmes dans la documentation, et l'IDE met les bons switches automatiquement pour les nouveaux projets, donc je ne vois pas le problème. Si vous n'êtes pas contents, vous pouvez toujours désactiver l'optimisation en question. Mais ne vous étonnez pas si ça augmente la taille de vos logiciels en C (voire en assembleur mal codé )!

Mais ça n'a rien à faire dans le linker! Pendant qu'on y est, le linker va désassembler mon code, regarder si y a pas de "move.w d0,d1;move.w d1,d0" et supprimer le deuxième "move" dans ces cas-là ?

C'est vraiment casse-gueule, de modifier un binaire comme ça sans crier gare... Et ce genre d'optimisation est facile à faire dans un compilateur, et c'est là qu'est sa place (et tu serais même d'accord avec moi si en ce moment précis tu n'étais pas confronté au pb )

Non. Ce n'est pas un bogue. C'est le comportement voulu. Mets le switch -d comme dit dans la doc.

ça transforme un programme totu à fait valide en un programme qui plante !

Il n'est pas valide puisqu'il n'y a pas le switch -d

Flanker
:

Non. Ce n'est pas un bogue. C'est le comportement voulu. Mets le switch -d comme dit dans la doc.

ça transforme un programme totu à fait valide en un programme qui plante !

Toutes les optimisations du linker ont cette éventualité (à faible probabilité). Lis la doc. Et bon sang, il n'y a pas de raison de ne pas mettre le switch -d et te taire.

Pollux
: Mais ça n'a rien à faire dans le linker! Pendant qu'on y est, le linker va désassembler mon code, regarder si y a pas de "move.w d0,d1;move.w d1,d0" et supprimer le deuxième "move" dans ces cas-là ?

Non, les optimisations du linker ne travaillent que sur des endroits où il y a un relogement. Le risque d'erreur serait trop grand sinon.

Le risque d'erreur est qd même grand.

Mais je suis sûr que tu n'es pas capable de me regarder en face et de dire sincèrement "cette optimisation a mieux sa place dans le linker que dans le compilateur"

Le linker a les moyens de le faire maintenant, donc c'est là que c'est fait.

Et le risque d'erreur est quasi-nul si l'assembleur ne cache pas ses labels au linker.

Réponds franchement

Pollux :
Mais je suis sûr que tu n'es pas capable de me regarder en face et de dire sincèrement "cette optimisation a mieux sa place dans le linker que dans le compilateur"

J'ai marre de passer des heures à discuter cette erreur d'utilisateur.

Pollux wins

Ta gueule!
!slap Vertyos
• Kevin Kofler slaps Vertyos around a bit with a large trout !

Demandé aussi poliment, tu peux tjrs courrir
Le #258 c'était à prendre comme une critique : "je sais pas quoi répondre, donc je kicke".

Pas de flood dans mon topic, merci.

!kick Kevin Kofler ? T'as floodé là

Gamin...

bah dis donc Kevin, si t'es aussi ouvert d'esprit, intelligent et pas cretin sur la tict board qu'ici, je comprends vraiment pas pkoi tlm ici trouve votre board merdique et mal gere

tu dois vraiment faire un moderateur de choc, je regrette de pas avoir vote pour toi...

!kick sBibi
--- Kick : sBibi kické(e) par Kevin Kofler
Lis le message ./263, crétin!

oh oui grand fou!

et puis je trouve que tu deviens tres vulgaire mon petit kevinichou
faisons l'amour, pas la guerre:
non?

#trifesses##trironces#