oui RLA, mais après ton RLA, faut bien que tu fasses quelque chose, tester un flag par exemple Edit: merde, en fait t'as raison, car c'est pareil avec le test de bit
Faut que j'arrête de penser 6502 moi lol ..
Dernière édition par TOUKO le 03 Juin 2011, 13:15, édité 1 fois.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
en fait, je prends une valeur dans cette liste par frame
ce mot de 16bits est décomposé comme cela :
sur 8 bits un compteur de &01 à &ff sur 8 bits un octet qui va être répéter autant de fois qu'indiqué par le compteur (de &00 à &ff)
quand le compteur sera à 0 je prends une nouvelle valeur dans la liste.
donc c'est vrai que je pourrai utiliser un test sur la valeur &00 du compteur pour indiquer la fin de liste mais je pensais l'utiliser pour indiquer un compteur 'infini'...
perdre effectivement un bit pour un test...cela aurait pu être une solution, mais au final cela ne fait gagner qu'un nop pour une perte important (128) au niveau du compteur.
mettre un ld bc,table_adr_end avant, c'est pas une solution car ça prends 3 nop pour 2 de gagnés au niveau des cps (vu que je fais cela qu'une fois par frame max) et encore pour le deuxième cp ça n'arrive qu'une fois toutes les 256/2 possibilités de la table (mot de 16 bits)
je fait bien un test sur la carry car RLA renvoi ton bit 7 dans la carry...
si tu fais la même chose avec bit x,r ça fait 2µs plus le saut conditionnel que tu es obligé de faire dans tous les cas (ou le ret, ou le call ou ce que tu veux de conditionnel bien entendu).
donc ton compteur, n'est jamais à 0 au départ .. Donc la valeur 0 valeur pourrai signifier la fin de ta table. avec le RLA de sharp, ca peut faire pas mal. Voire au pire 0 dans chaque byte.
donc c'est vrai que je pourrai utiliser un test sur la valeur &00 du compteur pour indiquer la fin de liste mais je pensais l'utiliser pour indiquer un compteur 'infini'...
perdre effectivement un bit pour un test...cela aurait pu être une solution, mais au final cela ne fait gagner qu'un nop pour une perte important (128) au niveau du compteur.
mettre un ld bc,table_adr_end avant, c'est pas une solution car ça prends 3 nop pour 2 de gagnés au niveau des cps (vu que je fais cela qu'une fois par frame max) et encore pour le deuxième cp ça n'arrive qu'une fois toutes les 256/2 possibilités de la table (mot de 16 bits)
merci en tout cas à tous de votre aide !
C'est une sorte de codage RLE ton truc donc tu peux réserver une valeur (genre #ff mais que tu ne test que sur l'octet qui défini le nombre de répétitions) donc ton nombre de répétition, passe de 0-255 à 0-254 ce qui n'est pas une perte énorme, et tu n'as plus qu'à tester un octet, ça me parait un compromis acceptable plutôt que gérer un compteur 16bits.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
shap a écrit :
En plus j'avais pas fait gaffe, mais si c'est un codage RLE ton truc, tu n'utilise pas 0 comme code de répétition je suppose...
Donc tu test octet répétition à 0 = fin de la table, un simple OR ou AND fera l'affaire, non ?
oui c'est tout à fait une solution possible... mais comme j'indiquai dans mon post précédent, je me demandais si je n'allais pas utilisé l'octet répétition à 00 pour dire que c'est une répétition infinie !
Merci à tous d'avoir phosphorés avec moi sur cette optim ! surtout que j'ai plein d'autres pgms en cours qui utilisent les tests fins de tables... donc ces réflexions peuvent servir à plein d'autres !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 24 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
