TIGCC 0.95 Beta 6 - Page 3

D'ailleurs, à mon avis, le linker pourrait aussi optimiser:

 bsr foo
toto:
 rts

en:

 bra foo
toto:
 rts

(Ça serait une optimisation vitesse seulement, pas une optimisation taille&vitesse comme celle qu'on a actuellement et qui restera certainement.)

je sais, mais ça permet de gagner qqes octets

ben oui mais il la ptet deja fait ailleur tu peut pas le savoir avec le peu de code qui est présent la

ça serait aps mieux comme optimisation ?

En tout cas, tout ceci ne change rien au fait que l'optimisation du linker n'est pas un problème si on passe le switch -d à A68k.

ça ne change rien au fait que vous perdez la compatibilité entre 0.94 et 0.95

Flanker
: ça serait aps mieux comme optimisation ?

Non, ça serait une optimisation intéressante en plus de celle qu'il y a actuellement! L'optimisation actuelle est une optimisation taille et vitesse, celle que je suggère en plus (pas à la place!) est une optimisation vitesse seulement.

Flanker> ni au fait que la plupart de ces optimisations sont très risquées... Je n'implémenterai jamais ça dans GTC

Flanker :
ça ne change rien au fait que vous perdez la compatibilité entre 0.94 et 0.95

Le jour où tu passes --optimize-code, tu n'es plus dans le cadre de la compatibilité.

Au fait, si, il y a un bogue: je viens de voir que le switch -d n'est pas mis par défaut dans l'IDE pour les nouveaux projets. Je vais demander à Sebastian de le mettre...

Pollux> c'est vrai ? j'ai hâte d'être en 2042, alors

Pollux
: Flanker> ni au fait que la plupart de ces optimisations sont très risquées... Je n'implémenterai jamais ça dans GTC

Tant pis, ton compilateur sera toujours inférieur au nôtre.

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.

Kevin Kofler
:

Pollux
: Flanker> ni au fait que la plupart de ces optimisations sont très risquées... Je n'implémenterai jamais ça dans GTC

Tant pis, ton compilateur sera toujours inférieur au nôtre.

(tu fais chier avec tes trolls)

Et pkoi?

Pollux
:

Kevin Kofler
:

Pollux
: Flanker> ni au fait que la plupart de ces optimisations sont très risquées... Je n'implémenterai jamais ça dans GTC

Tant pis, ton compilateur sera toujours inférieur au nôtre.

(tu fais chier avec tes trolls)

Et pkoi?

Parce que le nôtre (enfin: notre toolchain, vu que ce n'est pas le compilateur qui le fait) optimise mieux.

Et pkoi?

Et la solution suggérée au ./72, vous en pensez quoi?

Pollux :
Et pkoi?

Ben, parce que nous mettons des optimisations que tu ne mets pas.

Quelles optimisations ?

KK> Pourquoi pas...
Mais dans ce cas, comment préciser qu'on veut l'optimisation, sauf en appelant nous-même a68k ?

si c'est des optiimisations qui font gagner parfois quelques octets, ça ne changera pas énornément.

Flanker
: si c'est des optiimisations qui font gagner parfois quelques octets, ça ne changera pas énornément.

t'as pas encore compris la mentalité de Kevin toi

bah ce qui me gêne un peu, c'est qu'au moins certains de ses programmes sont optimisables, bien au-delà des quelques octets ...

Pollux
: Quelles optimisations ?

Clair. Je vois pas d'optimisation. Je vois un bug moi.

Sasume :
KK> Pourquoi pas... Mais dans ce cas, comment préciser qu'on veut l'optimisation, sauf en appelant nous-même a68k ?

Si l'optimisation est valide, elle sera effectuée. Le cas où elle n'est pas effectuée avec le switch -d est là où il y a un label et que donc l'optimisation (en sa forme actuelle, c'est-à-dire en virant le rts) n'est pas valide.

Albert Instinct
:

Pollux
:Quelles optimisations ?

Clair. Je vois pas d'optimisation. Je vois un bug moi.

L'optimisation tailcall:

 bsr toto
 rts

->
bra toto


Le problème est que si on a un label:

 bsr toto
foo:
 rts

avec les règlages par défaut actuels, A68k le vire lors de l'assemblage:

 bsr toto
 rts

et le linker donne:
bra toto
et tout saut vers foo va dans le vide. Le switch -d de A68k empêche ça. (Dans GNU as, c'est le switch --keep-locals qui est impliqué par --all-relocs, donc en général activé quand on optimise (sauf si on optimise sans range-cutting - là aussi, c'est un problème à règler).)

Ce que je compte faire maintenant (cf. ./72) est de mettre automatiquement le switch -d de A68k, ce qui fait que le linker voit:

 bsr toto
foo:
 rts

et reconnaît donc que l'optimisation tailcall n'est pas valide dans cette situation. Ça devrait par conséquent corriger le "bogue" que vous apercevez. (De mon point de vue: "Ça devrait rendre le système plus "idiot-proof" et ainsi éviter l'erreur d'utilisateur." Mais ce n'est qu'une question de termes, l'effet est le même: le problème sera corrigé.)

Alors, ma solution proposée vous va, sachant que vous ne percevrez plus aucun "bogue" (cf. l'explication ci-dessus)?

Kevin Kofler
:

Albert Instinct
:

Pollux
: Quelles optimisations ?

Clair. Je vois pas d'optimisation. Je vois un bug moi.

L'optimisation tailcall:
[pre:] bsr toto
rts[/pre]
-> [pre:] bra toto[/pre]

Fait par le compilateur. Raconte-moi les optimisations dont tu parlais dans .70 qui "rendraient GTC inférieur à TIGCC"... (je ne te parle pas de TIGCC avec l'ancien linker, je te parle de GTC, hein)

[EDIT : yAro, les [pre] à l'intérieur des [cite] foirent...]

Pollux
: Fait par le compilateur.

Pas dans les sources en assembleur, je suppose.

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.

Kevin Kofler
:

Pollux
: Fait par le compilateur.

Pas dans les sources en assembleur, je suppose.

C'est tout l'intérêt. Un code en assembleur, ça n'est pas censé être optimisé de manière automatique, parce que ça peut aboutir à toutes sortes de conflits. Tu as l'air de t'en foutre éperdument, mais c'est probablement parce que peu de programmes se servent de bcp d'ASM, ou alors parce que ceux qui s'en servent ne sont pas passé à TIGCC 0.95. Et puisque tu n'as pas l'air de me croire, je vais détailler un peu.

De même que l'assembleur n'a pas à optimiser move.w #6,d0 en moveq #6,d0 (même si ce serait correct dans 95% des cas) parce que ça peut foirer, l'assembleur n'a pas à transformer bsr/rts en bra parce que ça peut aussi foirer. Par exemple, on peut parfaitement imaginer la routine :

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

Je te défie de trouver aussi court en étant compilable avec TIGCC et les ""optimisations"" du nouveau linker... (avec exactement la même convention d'appel, bien sûr)

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

drawstuff:
  ...
  bsr drawline
  rts
drawline:
  moveq #1,d0 ; color mode ?
  ...

setglobalfont:
  ; 0=white
  ; 1=black
  ; 2=bold
  subq.w #1,d0
  bmi \nothingtobedone
  lea drawline,a0
  subq.w #1,(a0) ; transform to a moveq #0
  tst.w d0
  beq \nothingtobedone
  subq.w #4,-(a0) ; transform to a nop
\nothingtobedone
  rts

(et on ne peut pas se contenter de mettre un label devant les instructions qu'on ne modifie : ici, le label ne serait pas utilisé)


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

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

Pollux :
isinghostspace
bsr \chkghost
rts
\chkghost:
moveq #4,d0
and.w (a7),d0
rts
Je te défie de trouver aussi court en étant compilable avec TIGCC et les ""optimisations"" du nouveau linker... (avec exactement la même convention d'appel, bien sûr)

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

Sinon, effectivement, le mieux que j'ai trouvé est:

isinghostspace
  bsr \chkghost
\chkghost:
  addq.l #2,a7
  moveq #4,d0
  and.w (a7)+,d0
  rts

qui prend 2 octets de plus à cause du bsr +0. Mais la solution d'en haut (avec le label dummy) marche parfaitement (à condition d'assembler en activant les labels, évidemment).

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.

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. Mais bon:

(et on ne peut pas se contenter de mettre un label devant les instructions qu'on ne modifie : ici, le label ne serait pas utilisé)

Si! Le linker n'en a rien à f**tre que le label ne soit pas utilisé, il n'est pas aussi intelligent que ça. S'il voit qu'il y a un label, il n'optimise pas.

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