dilinger (./69) :
Tu utilises un tool fait maison pour ce profiler?

Il est fait à la main.
Mais ça serait effectivement pratique d'avoir un tool qui le fasse

ericde45 (./72) :
concernant l'optimisation, donc il faut que je m'efforce de virer les movei de ce que je comprends

En général oui : pour tout ce qui est adresses/valeurs utilisées dont on a besoin immédiatement de la valeur.

ericde45 (./72) :
est il aussi + pertinent de faire moveq + shlq ?

Alors, ce n'est pas forcement plus judicieux.

Avec les exemples que tu donnes, on ne gagne rien voir on peut même perdre un cycle.

instruction	Cycle1	Cycle2	Cycle3
movei #$8000, R26	Rword1	-	-
	Rword2	word1	-
	-	-	word2word1 > Wr26

instruction	Cycle1	Cycle2	Cycle3
moveq #1,R26	#1	-	-
shlq #15,R26	Rr26	-	Wr26
	-	Cr26	-
	-	-	Wr26

instruction	Cycle1	Cycle2	Cycle3
moveq #0,R26	#0	-	-
bset #15,R26	Rr26	-	Wr26
	-	Cr26	-
	-	-	Wr26

Si tu as besoin d'utiliser r26 tout de suite, le 1er cas est plus rapide de 1 cycle par rapport aux 2 autres cas.
Si tu n'as pas besoin d'utiliser r26 tout de suite, le délai du writeback supplémentaire est compensé et revient donc au même, mais c'est moins lisible

En remplaçant le movei par un move* (qui n'est pas movei) tu peux gagner un cycle si tu as besoin directement de R26.
Tous les move* (autres que movei) font 2 cycles au lieu de 3, du coup il faut les utiliser à des endroits stratégiques car ils peuvent casser le pipeline si on ne fait pas gaffe.
On le voit typiquement dans ton code avec les "move r26,r25" dans les "DSP_LSP_routine_interruption_I2S_pas_fin_de_sample_channel*"

Dans certains cas, il pourrait même être plus rapides d'utiliser un xor à la place de moveq afin de ne pas casser le pipeline : tout dépend en fait de ce qu'il y a avant et après

instruction	Cycle1	Cycle2	Cycle3
xor R26, R26	Rr26	-	-
(instruction utile)	RrX	Cr26	-
bset #15,R26	Rr26	CrX	Wr26
(instruction utilisant RX)	RrX	Cr26	WrX
(instruction utilisant R26)	Rr26	CrX	Wr26

et pour ce qui est de la lecture des variables, je peux faciler switcher à un systeme :

movei #premiere_variable,Rn (que je remplacerai par un movefa bien sur)
load (Rn),Ry

quand j'ai besoin de la 2eme variable

addq #4,Rn
load (Rn),Rx
( en interlacé bien sur )

Oui tout à fait.

Le but étant d'obtenir quelque chose comme ca :

instruction	Cycle1	Cycle2	Cycle3
movefa Rm,Rn	Rr'm	-	-
load (Rn), Ry	Rrn	-	Wrn
addq #4, Rn	Rrn	Mrn	-
(instruction utile)	-	Crn	Wry
load (Rn), Rx	Rrn	-	Wrn

une partie du code de ma première version du player YM7 était écrit comme cela mais c'est l'enfer à debugger
il faut ré-écrire le code de cette façon une fois que ça fonctionne.

Oui, vaut mieux faire un truc qui marche et ensuite optimiser par itération en vérifiant bien que chaque parties fonctionnent toujours (et non tout faire d'un coup )
C'est plus long à faire, mais on au moins on a une référence qui marche