Pollux
: Bon, je vais te faire un résumé des questions ouvertes auxquelles j'aimerais avoir une réponse :

OK, mais on peut arrêter après? Parce que c'est lourd. (Mais oui, le hors-sujet lancé par les trolls de vince et nitro est pire, je suis bien d'accord.)

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

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. De toute façon, plus on met dans les fichiers objet, mieux ça sera pour le futur débogueur qu'on prévoit toujours.

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