24Fermer26
PpHdLe 28/02/2008 à 08:30
Kevin Kofler (./24) :
Il manque un test si on n'est pas dans un segment qui ne permet pas le range cutting (cf. la fonction CanCutRange).

Non. Il est fait plus loin si on détecte qu'on peut faire une modif.
Là c'est juste pour éviter de perdre du temps si on est sûr qu'on peut pas faire de cutrange.
Kevin Kofler (./24) :
Le "near assembly" (switch -l) n'est pas possible pour adresser des BSS dans un FlashOS (ça essaie de faire du PC-relatif, pas du abs.w), donc ces lignes sont à supprimer.

Ok.
Kevin Kofler (./24) :
Ce test n'est effectivement plus correct, mais au lieu de le supprimer complètement, il vaudrait mieux vérifier que la section est la section main ou BSS.

Il n'a pas été supprimé. Regarde mieux.
Kevin Kofler (./24) :
Non. Je sais bien que OutputBin est obligatoire actuellement, mais sortir des TIB sans OutputBin, ça va être embêtant quand on voudra rajouter le support pour les 89u/9xu/v2u. (ExtendeD m'a permis de réutiliser (sous GPL) le code son tib2xxu qui est livré avec FreeFlash, d'ailleurs, donc si tu veux rajouter ça aussi, tu peux partir de là. smile.gif )

C'est pas prévu pour 2048 ?
Kevin Kofler (./24) :
Attention, pour tous ceux-là, on a encore un problème: l'assembleur marque actuellement toutes les opérandes de destination comme non-optimisables, parce qu'elles ne peuvent pas être PC-relatives et parce que ça évite de boguer sur move.w #qqch_qui_est_aussi_un_opcode,lbl_destination. J'ai bien peur qu'il faudra rajouter encore un flag (qui dit "ceci est une opérande de destination") et gérer ce flag partout (le traîter comme non-optimisable pour le passage en PC-relatif, et n'activer les optimisations de source ou de destination dans ton code que quand il le faut).

Et il faudrait voir aussi comment gérer au mieux les MOVEM et les BTST (d'ailleurs je ne suis pas sûr que l'optimisation des BTST fonctionne actuellement, je pense que l'assembleur met ça en "non optimisable" parce que c'est une destination), parce que ça devrait être marqué aussi pour trouver l'opcode sans risquer un faux positif sur les 2 octets devant.

Le mieux est probablement de:
* dans les assembleurs, mettre un flag qui signifie "l'opcode est à -4 plutôt que -2" (si on n'est pas dans un opcode, mais par exemple dans un dc.l, on continue à mettre le flag unoptimizable)
* dans le linker:
- si le flag n'est pas mis, chercher à -2 et faire les tests sur les opcodes qui se trouvent à -2 uniquement, - si le flag est mis, chercher à -4 et faire les tests sur les opcodes qui se trouvent à -4 uniquement.

Arg. Tout çà à faire. Mais c'est probablement inévitable.