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.

Et une grande partie de mon travail pour TIGCC 0.95 consistait justement à rajouter des informations au format objet pour rendre possibles ces optimisations. Par exemple, on n'optimise qu'en présence d'un relogement, les données pures ne sont pas touchées. Et pour les versions futures, je vais probablement mettre encore plus d'informations dans le format objet, pour avoir des optimisations qui sont sûres à 100% de ne modifier que les instructions visées, et pas quelque chose au milieu d'une instruction ou une donnée relogeable (variable globale contenant un pointeur) qui a par hasard la même structure.

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

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?

* en outre, est-ce qu'on est bien d'accord que les optimisations type mono-objet (transformation move.l foo.l,a0 -> move.l foo(pc),a0) et les optimisations type peephole (bsr/rts) sont complètement orthogonales ? Je suis pour les premières (elle permettent un gain substantif de taille sans changement de signification), et contre les deuxièmes (changement de signification du code, faible gain de taille)

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é... Et tes suggestions plus haut dans ce topic laissent supposer que tu veux rajouter d'autres peepholes.