La Place des Développeurs Temps d'exécution d'un programme (ASM)
Une âme charitable pourrait-elle expliquer en détail comment tester le temps d'exécution d'un programme en assembleur ?
Connaissez-vous des outils (émulateur ou autre) permettant de tester les performances d'un programme MSX ? Dans BlueMSX, les usage% et fps font référence au PC et non à l'ordinateur émulé.
Connaissez-vous des outils (émulateur ou autre) permettant de tester les performances d'un programme MSX ? Dans BlueMSX, les usage% et fps font référence au PC et non à l'ordinateur émulé.
On est toujours ignorant avant de savoir.
Il y a deux méthodes ...
La première : tu analyses ton code et tu note les T-states instruction par instruction (données dans la doc Z80), sachant qu'à un T-state correspond un temps d'éxécution déterminé. Très précis et plutôt facile à faire pour quelques dizaines de lignes de code, mais rapidement ingérable pour plusieurs centaines de lignes ...
La deuxième : tu initialises un compteur qui est incrémenté via le hook VBLANK, tu encadres ton programme par EI/DI, et puis tu vas lire le résultat, qui sera en 50e ou en 60e de secondes selon le réglage ... Bien évidemment, ce temps d'éxécution englobera aussi les temps d'éxécution de la routine de gestion des interruptions en ROM, mais de toutes façons, sauf cas particulier, c'est aussi le cas en temps normal. Et si tu veux vraiment avoir une mesure plus précise, il suffit d'enlever le temps d'éxécution (par comptage de T-states) de l'incrémentation du compteur, multiplié par le nombre d'appel du hook, c'est à dire la valeur du compteur.
EDIT : Et d'ailleurs, sauf erreur de ma part, ce compteur existe déjà : il s'agit du JIFFY, en $FC9E
La première : tu analyses ton code et tu note les T-states instruction par instruction (données dans la doc Z80), sachant qu'à un T-state correspond un temps d'éxécution déterminé. Très précis et plutôt facile à faire pour quelques dizaines de lignes de code, mais rapidement ingérable pour plusieurs centaines de lignes ...
La deuxième : tu initialises un compteur qui est incrémenté via le hook VBLANK, tu encadres ton programme par EI/DI, et puis tu vas lire le résultat, qui sera en 50e ou en 60e de secondes selon le réglage ... Bien évidemment, ce temps d'éxécution englobera aussi les temps d'éxécution de la routine de gestion des interruptions en ROM, mais de toutes façons, sauf cas particulier, c'est aussi le cas en temps normal. Et si tu veux vraiment avoir une mesure plus précise, il suffit d'enlever le temps d'éxécution (par comptage de T-states) de l'incrémentation du compteur, multiplié par le nombre d'appel du hook, c'est à dire la valeur du compteur.
EDIT : Et d'ailleurs, sauf erreur de ma part, ce compteur existe déjà : il s'agit du JIFFY, en $FC9E
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Pour la méthode 1 c'est pas jouable pour mon projet ; il est bien trop long et puis, y a trop de code dynamique qui ne s'exécute qu'en fonction de condition imprévisible.
Pour la 2e méthode, j'ai pas bien compris.
Le VBLANK est déclenché tous les 60ième de seconde (je suis en 60Hz) ; comment pourrait-il me permettre de calculer la vitesse d'un programme qui prend moins de temps qu'une frame ?
Je suppose qu'il y a une astuce avec EI/DI, mais je vois pas.
EDIT : Je cherche pas une méthode supra précise. Je veux juste savoir ou j'en suis à peu près en % d'utilisation du CPU sur une frame. Edité par aoineko Le 07/04/2011 à 11h22
Pour la 2e méthode, j'ai pas bien compris.
Le VBLANK est déclenché tous les 60ième de seconde (je suis en 60Hz) ; comment pourrait-il me permettre de calculer la vitesse d'un programme qui prend moins de temps qu'une frame ?
Je suppose qu'il y a une astuce avec EI/DI, mais je vois pas.
EDIT : Je cherche pas une méthode supra précise. Je veux juste savoir ou j'en suis à peu près en % d'utilisation du CPU sur une frame. Edité par aoineko Le 07/04/2011 à 11h22
On est toujours ignorant avant de savoir.
Ah tu veux mesurer un temps inférieur à une frame ... 
Tu peux utiliser la bonne vieille méthode de la couleur de bord.
Au début de ton code, tu changes la couleur du bord de l'écran, et tu la rétablis à la fin ...
Le seul problème, c'est la synchro par rapport à l'affichage. Tu forcer la synchro en faisant un 'HALT' avant l'éxécution du code, mais il y aura toute l'éxécution hors frame qui ne sera pas affichée (voir tableau ci-dessous, la partie après la ligne 192).
Tu peux utiliser la bonne vieille méthode de la couleur de bord.
Au début de ton code, tu changes la couleur du bord de l'écran, et tu la rétablis à la fin ...
Le seul problème, c'est la synchro par rapport à l'affichage. Tu forcer la synchro en faisant un 'HALT' avant l'éxécution du code, mais il y aura toute l'éxécution hors frame qui ne sera pas affichée (voir tableau ci-dessous, la partie après la ligne 192).
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Bien beau schéma.
On peut pas récupérer la ligne actuellement affiché ? En récupérant cette valeur à la fin de ma boucle principale, j'aurai une idée assez précise de mon temps d'exécution, non ? Edité par aoineko Le 07/04/2011 à 14h40
On peut pas récupérer la ligne actuellement affiché ? En récupérant cette valeur à la fin de ma boucle principale, j'aurai une idée assez précise de mon temps d'exécution, non ? Edité par aoineko Le 07/04/2011 à 14h40
On est toujours ignorant avant de savoir.
aoineko :
Bien beau schéma.
Merci
Je l'avais fait parce que j'avais besoin de visualiser la synchro code/affichage.
aoineko :
On peut pas récupérer la ligne actuellement affiché ? En récupérant cette valeur à la fin de ma boucle principale, j'aurai une idée assez précise de mon temps d'exécution, non ?
Pas à ma connaissance ... La seule chose que l'on peut faire, c'est générer une interruption VDP sur une ligne déterminée (HBLANK) par le registre 19. Tu pourrais éventuellement jouer la dessus par essai/erreur pour trouver ton temps d'éxécution, mais c'est plutôt lourd ...
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Bon, si c'est pas possible directement sur MSX, c'est au moins faisable via émulateur. Vous connaissez pas un émulateur avec des fonctionnalités de debug de ce genre ?
On est toujours ignorant avant de savoir.
Je crois que BlueMSX et OpenMSX proposent ce genre de choses ...
D'après ce que j'ai compris, ils peuvent mesurer les T-States entre 2 breakpoints.
Mais je n'en sais pas plus, et je n'ai jamais essayé.
D'après ce que j'ai compris, ils peuvent mesurer les T-States entre 2 breakpoints.
Mais je n'en sais pas plus, et je n'ai jamais essayé.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Au passage, si tu veux gagner du temps d'exécution, il y a quelques règles simples à suivre.
- Éviter d'utiliser les registres IX et IY.
- Éviter d'utiliser les push/pop.
- Travailler autant que possible sur les registres 8bit.
- Utiliser au maximum les registres dans boucles.
- Utiliser les astuces trouvées sur le net (voir des exemples aux liens suivants)
http://joewing.net/programs/z80op.shtml
http://wikiti.brandonw.net/index.php?title=Z80_Optimization
http://www.ftp83plus.net/Tutorials/z80opti.htm
- Éviter d'utiliser les registres IX et IY.
- Éviter d'utiliser les push/pop.
- Travailler autant que possible sur les registres 8bit.
- Utiliser au maximum les registres dans boucles.
- Utiliser les astuces trouvées sur le net (voir des exemples aux liens suivants)
http://joewing.net/programs/z80op.shtml
http://wikiti.brandonw.net/index.php?title=Z80_Optimization
http://www.ftp83plus.net/Tutorials/z80opti.htm
GDX :
Au passage, si tu veux gagner du temps d'exécution, il y a quelques règles simples à suivre.
- Éviter d'utiliser les registres IX et IY.
- Éviter d'utiliser les push/pop
- Éviter d'utiliser les registres IX et IY.
- Éviter d'utiliser les push/pop
Et bien là, il est déjà mal barré Aoineko
Son compilateur C génère un code qui use et abuse de IX, IY et de push/pop
Mais bon c'est son choix
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Ce qu'il a de bien avec le C, c'est que rien ne m'empêche de passer en assembleur une section si je la trouve trop gourmande. 
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie