Tester un bit - Page 1

Cette question va paraître inutile mais bon.

Voilà, je voudrais tester un bit à un endroit bien précis de la mémoire.

Du genre:

data:
dc.b 125,85,47,52....


data:
movem.l d0/d1/a0,-(a7)
lea.l data_ptr(PC),a0
move.b_ data_bitn,d1
btst d1,(a0)+
bne no_impulsion
bset #0,($60000E)
bra suite
no_impulsion:
bclr #0,($60000E)

suite:
addq.b #1,data_bitn
cmp.b #8,data_bitn
beq add_ptr_data
bra end_data

add_ptr_data:
addq.l #1,data_ptr
clr.b data_bitn

end_data:
movem.l (a7)+,d0/d1/a0
rts

Mais quand je fais btst d1,(a0)+ ça ne fonctionne pas.

c'est quoi _data_bitn et data_ptr ?

Au fait, ton code n'utilise presque que des adresse absolues.
En plus d'être relativement lent, ça fait grossir la taille de l'exécutable pour fournir la table de relogements et ça ralentit le lancement du programme (mais ça c'est négligeable)

Data_bitn s'est le bit n° à extraire dans l'octet en court.
En bref je veux parcourir une série de données bit à bit. Si le bit est à 1, impulsion, sinon pas d'impulsion.
J'avance mon pointeur de données data_ptr, lorsque j'ai finis de parcourir tout les bit de l'octet en cours.

Au fait, ton coda n'utilise presque que des adresse absolues. En plus d'être relativement lent, ça fait grossir la taille de l'exécutable pour fournir la table de relogements et ça ralentit le lancement du programme (mais ça c'est négligeable)

Ah bon, il faut vaiment que ce code soit optimisé en vitesse, que dois-je faire?

Tu peux mettre l'adresse de DataBitn dans un registre d'adresse, et au lieu de faire addq.b #1,DataBitn, tu ferais addq.b #1,(a0), ce qui serait déjà bien plus rapide.
Ou bien, tu peux mettre DataBitn dans un registre pendant toute la fonction et à la fin seulement, tu fais un move.b d1,DataBitn.
Ou bien, si possible, tu n'utilises pas du tout de variable globale, tu n'utilises qu'un registre (impossible si plusieurs fonctions se servent de DataBitn).

Mais à mon avis, une autre technique à essayer (de tête, je ne sais pas si ce sera plus rapide, mais c'est possible), c'est un truc du genre :

DonnéeSuivante:
move.b (a0)+,d0
Boucle:
lsr.b #1,d0
beq.s DonnéeSuivante
bcc.s no_impulsion
bset.b #0,$60000E
bra.s Boucle
no_impulsion:
bclr.b #0,$60000E
bra.s Boucle

Bon, là ça ne marcherait pas parce que ça bouclerait à l'infini, mais c'est pour que tu voies le principe.

Euh ouais, il y a peut-être un peu trop de branchements, ça doit sûrement être optimisable à ce niveau là, mon exemple

Ah ouai, là je comprend mieux, l'optimisation. par contre je ne peut pas stocker l'adresse de data ou databitn dans un registre... Je ne peux faire ça que avec des variables. Je sais que s'est lent, mais je ne peux faire autrement.

Pourquoi tu ne peux pas stoquer le contenu de databitn dans un registre ?

>geogeo>btst d1,(a0)+
Pourquoi (a0)+?

Pour les vars, si tu peux pas les passer par registres, tu peux peut-être par la stack?

Pourquoi (a0)+?

Pour extrait l'octet.

Pourquoi tu ne peux pas stoquer le contenu de databitn dans un registre ?

Ca à un rapport avec ma librairie et il met impossible de passer par le stack et encore moins par registre. Le test des bits ne ce fait pas en continue.

Voilà je veins de créer la fonction et ça fonctionne très bien. Mais je ne voit pas ce que je peux optimiser dans le cas où je ne peux pas utiliser de registre ou le stack pour sauvegarder mon pointeur et le le numéro du bit à tester.

Pourquoi (a0)+?

Pour extraire l'octet.

Mais pourquoi (a0)+ ? (la question portait sur le +)

ça permet de passer à la donnée suivante en incrémentant a0 (d'où le nom du label )

Mais pourquoi (a0)+ ? (la question portait sur le +)

Excuse moi. En effet ça extrait la donnée puis désempile de 1 octet a0.

Pour lire bit par bit, moi, j'utiliserais:

 subq.b #1,d1
 bcc.s positive
 moveq.l #7,d1
 addq.l #1,a0
positive:
 btst.b d1,(a0)

Attention, ce n'est peut-être pas optimal.

Et c'est le type de parcours utilisé par exemple pour les sprites: on lit de gauche à droite. C'est-à-dire qu'on commence par le bit 7 et qu'on va jusqu'au bit 0.

Je propose cela:

data: 
	movem.l d0/d1/a0/a1,-(a7) 
	lea	data_ptr(PC),a0 
	move.l	(a0)+,a1
	move.b	(a0)+,d1
	moveq	#1,d0
	and.b	d1,d0
	move.b	d0,$60000E
	lsr.b	#1,d1	
	subq.b	#1,(a0)
	bne.s	\End
		move.b	#8,(a0)
		move.b	(a1)+,-(a0)
		move.l	a1,-(a0)
		movem.l (a7)+,d0/d1/a0/a1
		rts 		
\End:	move.b	d1,-(a0)
	movem.l (a7)+,d0/d1/a0/a1
	rts
	
data_ptr	dc.l	0
data_value	dc.b	0
data_bit	dc.b	0	

C'est fait a la va-vite.

J'avais fait ça:
move.l d0,-(a7)
move.l a0,-(a7)

move.l wav_ptr(PC),a0
move.b wav_bit,d0

btst d0,(a0)+
beq no_impulsion
bset #0,($60000E)
bra suite_wav

no_impulsion:
bclr #0,($60000E)

suite_wav:
addq.b #1,wav_bit
cmp.b #8,wav_bit
ble end_wav

add_ptr_wav:
addq.l #1,wav_ptr
clr.b wav_bit

end_wav:
move.l (a7)+,a0
move.l (a7)+,d0
bra done_voice2

Ce que voulais dire, pour mon plus c'est
_ pourquoi augmenter d'un byte(octet), alors que la logique est de passer au bit suivant, ce que fait déjà la fin de la routine:

addq.b #1,data_bitn
cmp.b #8,data_bitn
beq add_ptr_data
bra end_data

add_ptr_data:
addq.l #1,data_ptr
clr.b data_bitn 

_ pourquoi tu changes la valeur de a0, alors qu'a0 n'est plus utilsé jusqu'à ce que tu le restore.

Je t'accorde que c'est pas très important, mais éviter une incrémentation inutile serait un bon début.

Ca va pas ce que j'ai fait ?

Si si, il est plus rapide?

Comptes les cycles, tu verras. Ou benche

i vu moveq.l #7,d1 ... btst.b d1,(a0)J'ai pas trop lu, la flemme, mais j'aPour tester le dernier bit d'un octet, il y a plus rapide.

Ce n'est pas toujours ce bit qui va être testé

Lis ce qu'il y a entre les deux, et au-dessus aussi, et tu sauras pourquoi j'ai fait comme ça... C'est un exemple parfait de citation hors du contexte.

C'est optimisable si le code qui suit n'est pas très long. C'est ce que je veux dire.

C'est faux. On a besoin d'avoir 7 en %d1 la prochaîne fois que ce morceau de code est exécuté.

Ok.