Si ta table est de longueur fixe, tu initialise une variable de la longueur de ta table que tu décrémentes .. A 0, tu es à la fin !! Ou tu peux tester si l'adresse de ton pointeur, correspond à celle de la fin de ta table ..
Si elle est variable, je mettrai un caractère particulier de fin de table ..
Si tu peux utiliser le registre BC, le top c'est de faire un CPI qui fait en une seule instruction - un INC HL - un DEC BC - positionne le flag V tant que BC!=0
Si tu peux utiliser le registre BC, le top c'est de faire un CPI qui fait en une seule instruction - un INC HL - un DEC BC - positionne le flag V tant que BC!=0
Ah oui c'est pas mal comme instruction ça ..
CPI, ne fait que comparer et incrémenter non ..
Ce serai pas plutôt CPIR pour faire tout ce que tu as dit ???
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Demoniak a écrit :
Si tu peux utiliser le registre BC, le top c'est de faire un CPI qui fait en une seule instruction - un INC HL - un DEC BC - positionne le flag V tant que BC!=0
euh...
CPI ça compare le contenu de A avec celui de (HL) puis ça fait effectivement inc hl, dec bc
mais là, je cherche à optimiser la routine en terme de timing... je vais remplacer le "etc." par un exemple + le timing en première colonne :
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
TOUKO a écrit :
Bah je connais pas l'asm z80 mais ..
Si ta table est de longueur fixe, tu initialise une variable de la longueur de ta table que tu décrémentes .. A 0, tu es à la fin !! Ou tu peux tester si l'adresse de ton pointeur, correspond à celle de la fin de ta table ..
Si elle est variable, je mettrai un mot particulier de fin de table ..
effectivement avec un caractère particulier en fin de table, ça pourrait un peu optimiser :
on gagne 1 nop sur le temps mini et une fois (tous les 256) on gagne 6 nop... par contre cela marche à condition que le mot de fin ne soit pas utilisé dans les datas...
Code :
table_adr_ptr equ $ +1 3 ld hl,table_adr 2 ld e,(hl) 2 inc hl 2 ld d,(hl) 2 inc hl 1 ld a,e 1 or d 3/2 jr nz,label_adr_nz 3 ld hl,table_adr label_adr_nz 5 ld (table_adr_ptr),hl --- 21 mini /23 max
effectivement avec un caractère particulier en fin de table, ça pourrait un peu optimiser :
on gagne 1 nop sur le temps mini et une fois (tous les 256) on gagne 6 nop... par contre cela marche à condition que le mot de fin ne soit pas utilisé dans les datas...
Oui bien sur, mais si tu utilises des words (et non des bytes), tu peux par exemple signer ton word de fin .. Sinon reste à savoir ce que tu mets comme valeurs dans ta table .
Là elle apparaît fixe, pourquoi ne calcules tu pas son adresse de fin ??? Ou sur le premier word, tu ne met pas le nombre d'entrées qu'elle contient ?? ,tu le mettrais dans le registre BC
Après, dans l'esprit de ton ancienne routine (qui teste la valeur du pointeur avec adresse commune), on peut difficilement faire mieux (6 nop sur 255 poids faibles, 11 nop 1 fois tous les 256 octets, 10 pour l'égalité.)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
TOUKO a écrit :
Megachur a écrit :
effectivement avec un caractère particulier en fin de table, ça pourrait un peu optimiser :
on gagne 1 nop sur le temps mini et une fois (tous les 256) on gagne 6 nop... par contre cela marche à condition que le mot de fin ne soit pas utilisé dans les datas...
Oui bien sur, mais si tu utilises des words (et non des bytes), tu peux par exemple signer ton word de fin .. Sinon reste à savoir ce que tu mets comme valeurs dans ta table .
Là elle apparaît fixe, pourquoi ne calcules tu pas son adresse de fin ??? Ou sur le premier word, tu ne met pas le nombre d'entrées qu'elle contient ?? ,tu le mettrais dans le registre BC
en fait, c'est une liste de valeur qui me servent pour la suite... si je stocke un compteur dans bc il faut que je rajoute avant le code :
compteur_ptr equ $ +1 ld bc,compteur dec bc ld (compteur_ptr),bc
ce qui est plus couteux que de tester la fin de la table en fait...à moins qu'il y a une autre optimisation..
@ longshot : oui, j'aurai pu utiliser la pile si j'en ai pas besoin...par contre pour tester le dépassement de la fin de table, je dois utiliser quelque chose comme cela : ld hl,0 add hl,sp etc... donc pas forcément moins couteux en temps z80 au final je pense.
merci encore de votre aide. je vais donc en rester pour l'instant sur cette version sauf si quelqu'un trouve encore une optimisation !
d'après ton exemple, il semble que ta table stock des données 16 bits non ?
si c'est le cas, utilises-tu les 8bits de poids fort ? si il te reste des valeurs que tu n'adresses pas, un flag sur le poids fort me semble le plus efficace, et tu n'as qu'un octet (ou un bit éventuellement) à tester.
Le coup du bit est pas mal, style le bit 15, serai très efficace aussi .
Oui mais le problème du bit est que tu perds beaucoup de possibilité à écarter un bit de ta valeur.
dans ton exemple (bit 15) on passe de 2^16 possibilités à 2^15 ce qui revient à diviser par 2.
alors que si il réserve une seule valeur genre #ff, il ne perd qu'une seule possibilité de codage sur ses datas.
et l'avantage de le prendre sur le poids fort c'est, outre le fait de n'avoir qu'un octet à tester, que ça n'interdit en rien le #ff sur le poids faible.
Après tout dépend de ce qu'il veut coder dans sa table.
Tout à fait .. Effectivement, tu as raison pour la valeur, après si il peut se permettre de perdre le bit 15, faut voir si un test de bit sur le z80 est plus rapide qu'un test sur une valeur .
Dernière édition par TOUKO le 03 Juin 2011, 12:59, édité 1 fois.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 13 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
