J'ai fait un petit
profiling et suis étonné du résultat.
Près de 27% du temps est passé dans cette routine qui n'a pas l'air de faire de gros calculs:
Fichier(s) joint(s):
zz.png [ 38.17 Kio | Vu 4020 fois ]
En fait 90% du temps est passé dans l'attente de $E7E7, c'est à dire la VBL. Il y a là (172507+863428)*10 = 10359350 cycles machine "perdus" sur 814 appels, soit 1272 cycles en moyenne par appel. Je ne sais pas s'il y a moyen de faire passer une partie des calculs utiles juste avant cette attente pour faire quelque chose et attendre moins longtemps.
Petites optims (taille+vitesse):
* Comme tu accèdes souvent aux adresses $74xx, je me demande s'il ne serait pas possible de faire pointer DP sur $74 et gagner un cycle à chaque accès mémoire.
* Le code utilise pas mal de branchements longs quand c'est pas nécessaire. L'assembleur ne propose pas d'optimiser en des sauts courts ? j'ai une macro C dans ugBasic qui génère un code asm optimal:
https://github.com/Samuel-DEVULDER/ugba ... .c#L44-L59Fichier(s) joint(s):
Image3.png [ 29.41 Kio | Vu 4020 fois ]
Je pense qu'il doit être possible d'en dériver une macro ASM6809 qui ferait pareil.
Autre chose: je vois dans ce code l'incrément d'un compteur 16bits en $744C. Cela utilise l'accu D. C'est bien, mais il y a un double accès mémoire alors que 255 fois sur 256 l'octet mémoire n'est pas modifié. Aussi un simple
Code:
INC $746C
BNE SUITE
INC $746B
SUITE:
...
est paradoxalement plus rapide puisqu'il tourne en moyenne à ((7+3)*255+(7+3+7)*1)/256 = 10.02 cycles en moyenne contre 16 systématiquement avec le LDD/ADDD/STD.