SCPCD (./15) :
@DEATH, parler d'optimisations est un peut prématuré pour le moment, mais il y a des pièges dont tu es tombés dedans

Sur une vrai Jag, les MOVEx sont en 2 cycles et non 3 (comme quasi toutes les autres instructions) du coup les codes suivants sont identiques niveau cycle :
movei #D_FLAGS,r30 load (r30),r29 moveq #0,r24 move r24,r25 movei #D_FLAGS,r30 moveq #0,r24 load (r30),r29 move r24,r25 Le MOVEI prend un cycle de plus que les autres MOVE, mais il prend 3 slot 16-bit au lieu de 1, du coup la différence de cycle est compensée et c'est garantie que le registre est ready pour l'instruction suivante.


Je pense qu'il y a effectivement plein de truc "à priori" inutile, mais n'ayant jamais vraiment joué avec le DSP, je ne saurais pas garantir ce qui est vraiment obligatoire ou pas, pour ça que je préfère l'approche de DrTypo de d'abords trouver le pb et après simplifier.

Ah oui tiens je n'avais pas fait gaffe pour les move (en même temps c'est logique vu qu'il n'y a pas de calcul par l'ALU)

C'est vrai qu'en regardant cycle par cycle c'est chaud.... que ce soit le code entrelacé ou non on obtient des situations de colisions...
Des doubles écriture aux registres (ce qui je crois n'est pas possible), des triples accès aux registres (impossible aussi)....
J'ai même l'impression que dans le 1er cas non entrelacé le LOAD peut potentiellement se terminer après le dernier move r24,r25...

c'est désespérant.

Il faudrait une sorte d'assembleur/simulateur pour voir comment vont être exécuté les instructions à chaque cycle

Quel casse tête