TIGCC 0.95 Beta 6 - Page 2

Albert Instinct :
Le bug dans le linker qui optimisait bsr+label+rts par bra+label a-t-il été corrigé ?

Ce n'est pas un bogue, ça a été dit et redit. Il faut mettre l'option -d à A68k, l'IDE la met par défaut pour les nouveaux projets, on ne peut pas faire plus.

Ah, là c'est déjà plus clair. C'est bizarre en effet. (Et ce comportement bizarre est toujours là dans la bêta 6.)

Oui.

Ce n'est pas un bogue, ça a été dit et redit. Il faut mettre l'option -d à A68k, l'IDE la met par défaut pour les nouveaux projets, on ne peut pas faire plus.

Ce n'est pas un bogue mais un mauvais feature et compte sur l'IDE pour ratrapper ca c'est pas une bonne solution car tout le monde ne se sert pas de l'IDE

surtout qu'il n'apparaissait pas avant

Uther
:

Ce n'est pas un bogue, ça a été dit et redit. Il faut mettre l'option -d à A68k, l'IDE la met par défaut pour les nouveaux projets, on ne peut pas faire plus.

Ce n'est pas un bogue mais un mauvais feature et compte sur l'IDE pour ratrapper ca c'est pas une bonne solution car tout le monde ne se sert pas de l'IDE

En ligne de commande, si tu ne mets pas explicitement --optimize-code, le linker ne fera pas cette optimisation. Donc si tu mets --optimize-code --cut-ranges en ligne de commande, tu as vraisemblablement lu la documentation, et tu sais qu'il faut aussi mettre -WA,-d si tu utilises A68k. Si tu copies bêtement des switches mal choisis sans lire la documentation, c'est ton problème.
Et j'ai déjà dit que j'avais marre de cette discussion, alors soit tu arrêtes de raler au sujet de cette erreur d'utilisateur évidente, soit je te kicke. (Dans un bug tracker, je mettrais ton "bogue" en RESOLVED INVALID. L'équivalent ici, c'est le kick.) La même chose est valable pour Flanker, qui est celui qui a reporté le bogue à l'origine, et pour Thibaut qui l'a fait ressortir ici alors que j'avais dit explicitement que le cas était clos et que ce "bogue" ne sera pas "corrigé" (parce que ce n'est pas un bogue) dans le topic sur la bêta 5.

Je ne comprends pas du tout en quoi ça vous dérange de mettre un switch pour A68k qui, de plus, est écrit dans la doc.

moi j'ai résolu le problème : je suis repassé à la version 0.94. tant pis pour ceux qui compileront avec la 0.95

Bon, tu l'as voulu:
<FLAME>
Bon sang, pourquoi perds-tu ton temps à repasser à une version TOTALEMENT OBSOLÈTE de TIGCC qui n'est plus du tout supportée (bref, si tu as un problème avec, je te dirai: Tant pis, c'est corrigé dans la 0.95. Et il y a pas mal de cas comme ça pour A68k) alors qu'il suffirait de mettre DEUX CARACTÈRES dans les options de A68k dans l'IDE ou SIX CARACTÈRES en ligne de commande!!! C'est une "solution" totalement stupide et injustifiée.
</FLAME>

Et au passage:

Flanker
: Je préférais l'ancien linker ; c'est le 4eme programme que le nouveau linker me fait planter.

Ce n'est pas le linker qui fait planter ton programme, mais le fait que tu ne l'utilises pas correctement. C'est une erreur d'utilisateur. Ça te coûte quoi de mettre un switch de A68k???

Jusqu'à présent j'ai eu la chance de m'en apercevoir mais ça ne sera peut-être pas toujours le cas

Il suffit de toujours mettre le switch -d, comme ça tu n'auras pas ce problème.

Mais Kevin, reconnaît quand même que votre optimisation est mal fichue...

Sasume
: Mais Kevin, reconnaît quand même que votre optimisation est mal fichue...

Les défauts de l'optimisation sont documentés. Ce n'est pas la faute du linker si l'assembleur lui cache les symboles par défaut.

je n'ai plus confiance dans le nouveau linker, c'est tout. Il me skippe des labels alors qu'il ne devrait pas. Dans mon code, j'ai

 beq _end
 bsr   dfdsfsd
_end:
 rts
_end_700
 ...
 rts

le bloc
_end:
rts

est complètement dégagé !

Ce n'est pas non plus de la faute du linker si il a été codé pour faire une optimisation qu'il n'a pas à faire... ?
Vous devriez ne pas activer ce genre « d'optimisations » par défaut ; elles ne devraient être disponibles qu'avec un flag lors de l'appel du linker...

Et puis le rouge en énorme, je doute que ce soit très intelligent...

Flanker :
je n'ai plus confiance dans le nouveau linker, c'est tout. Il me skippe des labels alors qu'il ne devrait pas. Dans mon code, j'ai

beq _end
bsr dfdsfsd
_end:
rts
_end_700
...
rts
le bloc
_end:
rts
est complètement dégagé !

C'est encore parce que tu n'as pas mis le switch -d.

Flanker> Mais pourquoi tu fais un bsr juste avant un rts ?
Écris directement la routine.

Parce que le bsr n'est pas tjs exécuté...

et si la routine etait utilisé a plusieurs endroits différents ? (genre une Sub Runtime, d'ou BSR et pas "BRA")

Sasume :
Ce n'est pas non plus de la faute du linker si il a été codé pour faire une optimisation qu'il n'a pas à faire... ? Vous devriez ne pas activer ce genre « d'optimisations » par défaut ; elles ne devraient être disponibles qu'avec un flag lors de l'appel du linker...

C'est déjà le cas! Les optimisations ne sont activées que si tu mets --optimize-code. Et si on utilise l'IDE pour créer un nouveau projet, -d est mis. Le seul problème, c'est la conversion des vieux projets dans l'IDE, qui met les optimisations (parce que sinon, pas mal de gens vont oublier de les mettre, alors qu'elles sont en général une bonne idée), mais pas le switch -d (parce que les switches ne sont pas modifiés).

Sasume :
Flanker> Mais pourquoi tu fais un bsr juste avant un rts ? Écris directement la routine.

Pollux
: Parce que le bsr n'est pas tjs exécuté...

Il peut quand-même remplacer le bsr par un bra!

Pollux
: Parce que le bsr n'est pas tjs exécuté...

Godzil
: et si la routine etait utilisé a plusieurs endroits différents ? (genre une Sub Runtime, d'ou BSR et pas "BRA")

Et alors ?

Je dois être à l'ouest puisque vous êtes deux à me contredire, mais je ne comprends pas le problème.

Le rts peut être modifié par du code auto-modifiant...

Sasume
:

Pollux
: Parce que le bsr n'est pas tjs exécuté...

Godzil
: et si la routine etait utilisé a plusieurs endroits différents ? (genre une Sub Runtime, d'ou BSR et pas "BRA")

Et alors ?
Je dois être à l'ouest puisque vous êtes deux à me contredire, mais je ne comprends pas le problème.

heu quand tu ecrit du C, si tu fait une fonction, c'est pour pouvoir l'utiliser un peu partout non ? sans avoir le code copié a chaque fois qu'on l'apelle (sauf avec inline, mais c une cas particulier) quand tu utilise bsr, c'est pour appeler une routine externe non ? et cette routine peu etre partagé a plusieurs endroit différent dans le code, alors pq il devrait le copier a chaque fois inutilement ?

Pollux> OK, je comprends.
Merci.

En fait je sais pas si c pour ça, mais du code inutile, ça arrive, surtout en ASM (notamment à cause de #ifdef).

c'est le genre d'optimisations que je fais uniquement quand je suis sûr que je ne mettrais pas de code après le bsr.
Ou alors, je fais parfois des bsr qui font parfois un rts pour quitter, parfois un jump pour quitter, et je dois alors poper systématiquement un long de la pile.

po tres propre

Godzil
: heu quand tu ecrit du C, si tu fait une fonction, c'est pour pouvoir l'utiliser un peu partout non ? sans avoir le code copié a chaque fois qu'on l'apelle (sauf avec inline, mais c une cas particulier) quand tu utilise bsr, c'est pour appeler une routine externe non ? et cette routine peu etre partagé a plusieurs endroit différent dans le code, alors pq il devrait le copier a chaque fois inutilement ?

Je parle de faire ça :
ion: ; code rts

Remplacer ce code :programme:
; code
  bsr fonction
; code
  bsr fonction
  rts

fonct

rts

par :programme:
; code
  bsr fonction
; code
fonction:
; code