Pollux
:

Kevin Kofler
:

* ton argument principal est que les optimisations du linker servent pour l'assembleur, qd il y a plusieurs .asm; à ceci, je réponds que la seule sémantique valable est celle d'A68k avec tous les fichiers mergés; parce que le format objet contient trop peu d'informations (différence entre bra.w et bra tout court, différence entre dc.w 0x1234 et move.l $direct,a0 ...) pour que les transformations effectuées soient sûres

Mon avis reste que la compilation séparée a des avantages importants qu'il ne faut pas abandonner au profit d'une optimisation qui peut aussi être effectuée autrement (dans le linker). Si on veut compiler tout en un, il y a le hack des include de code, mais c'est ce que c'est: un hack.

Je voudrais bien entendre ces "avantages importants"... Le temps d'assemblage est négligeable. Et je ne parle pas d'include, je parle d'attendre le linking final pour produire du code binaire.

Les avantages:
* Temps d'assemblage économisé (pas nécessairement négligeable).
* Gestion des librairies statiques.
* Gestion du linking entre sources en des langages divers (C, GNU as, A68k, voire d'autres qui pourraient être introduits plus tard). La méthode du tout-en-un ne marche plus si on a du A68k et du GNU as.
Et puis, pour "attendre le linking final pour produire du code binaire", il faut à un moment convertir ça en include, et aussi renommer tous les labels non-exportés pour éviter les conflits. C'est beaucoup plus dur que ça n'a l'air, sachant que les assembleurs n'ont aucun support pour l'assemblage de plusieurs sources en même temps. Et puis je trouve que c'est au linker de faire le linking, pas à l'assembleur.

Bah oui, mais pour gérer vraiment tous les cas tordus (du genre move.w #0x6000,d0; dc.w l1-l2), il faut faire extrêmement gaffe et la manière légère avec laquelle vous avez fait ça laisse supposer qu'il y a des chances qu'il reste des bugs...

Ce cas est déjà géré correctement. C'est à ça que sert le mode all-relocs: Il y aura un relogement vers l1 relatif à l2 (relogement de différence d'adresses). Le linker calcule l'offset final après les optimisations qui suppriment du code.

La seule façon où on est sûr de ne pas faire d'erreur, c'est d'assembler au dernier moment (et qui est certainement bien plus simple à implémenter que vos hacks qui consistent plus ou moins à désassembler le code objet).

Notre méthode consiste surtout à repérer les relogements, et nous servir des relogements pour optimiser. Seulement s'il y a un relogement, nous regardons ce qu'il y a devant pour identifier l'instruction.

De toute façon, plus on met dans les fichiers objet, mieux ça sera pour le futur débogueur qu'on prévoit toujours.

De toute façon le débuggeur travaille toujours à un niveau supérieur (lignes de source), non?

Tout débogueur a besoin d'informations de débogage dans le fichier objet pour fonctionner. La nature exacte des informations dont nous aurons besoin n'est pas encore connue. Ça va se fixer au fur et à mesure de l'implémentation, quand il sera temps de réaliser le débogueur.

Oui, ils sont orthogonales, mais il y a un seul type de peepholes dans le linker, et c'est l'optimisation tailcall. Et nous avons vraiment fait tout notre possible pour minimiser les erreurs: optimisation seulement en présence d'un relogement (par exemple, nous ne touchons pas à jsr (%a0);rts), optimisation seulement s'il n'y a pas de label entre les 2 instructions, ... Le risque d'erreurs est vraiment minime sous ces conditions.

Non, c'est toujours assez risqué...

Je ne trouve pas, moi. Désolé, je crains que nous resterons en désaccord sur ce point.

Et tes suggestions plus haut dans ce topic laissent supposer que tu veux rajouter d'autres peepholes.

Je proposais juste d'élargir le peephole existant, mais je vois maintenant que ce n'est probablement pas une bonne idée. De toute façon, le cas généralisé ne serait plus qu'un gain de vitesse sans gain de taille, donc il ne m'intéresse pas vraiment (contrairement au cas particulier actuel qui optimise en taille et vitesse).

En tout cas, aucune autre optimisation style peephole n'est actuellement prévue du côté du linker.