23Fermer25
Kevin KoflerLe 28/02/2008 à 07:24
PpHd (./23) :
+ if (!Data || Reloc->Unoptimizable || Reloc->Size != 4 || !Section->CanCutRanges)

Il manque un test si on n'est pas dans un segment qui ne permet pas le range cutting (cf. la fonction CanCutRange).
+      if (OptimizeInfo->NearAssemblyResult >= 0)
+        OptimizeInfo->NearAssemblyResult += 2;

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.
-			if (Reloc->Target.Symbol->Parent != MainSection)
-				FailWithError (CurFileName, "Cannot emit reloc to `%s' in different section.", Reloc->Target.SymbolName);

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.
 					Warning (NULL, "Flash OS support in TIGCC is experimental.");
+					OutputBin = TRUE;

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)
Limitations: je n'ai la détection de code que celle déjà supporté par ld-tigcc.
Il faut rajouter le support des instructions suivantes couic
move. reg/(reg)/(reg)+,abs.l
move. -(reg),abs.l
move. off(reg),abs.l
move.l #imm,var
clr var.l
tst var.l
cmpi #imm,abs.l
addi #imm,var.l
subi #imm,var.l
ori #imm,var.l
andi #imm,var.l
eori #imm,var.l
movem. ...,var.l(Dites moi si j'en ai oublié).

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.
Sous l'assembleur, serait-il possible de spécifier par section, l'option cut-ranges ?

Difficilement, parce qu'il faudrait aussi changer de mode dans l'assembleur (all relocs ou non) pour que ce soit vraiment utile.