manière la plus rapide de placer un bit

manière la plus rapide de placer un bit - ASM - Programmation

Marsh Posté le 27-06-2003 à 11:05:01    

:hello:
 
je cherche un algo le plus rapide possible en assembleur pour placer un bit dans un octet à une position que je choisis, une sorte de fonction du style :
 
SETBIT(char *chaine, int bitposition, int bitvalue)
avec bitvalue = 0 ou 1.
 
j'arrive pas à le faire en assembleur. quelqu'un pour m'aider ?


---------------
Bougredane et bougre d'andouille ne font qu'un !
Reply

Marsh Posté le 27-06-2003 à 11:05:01   

Reply

Marsh Posté le 27-06-2003 à 11:09:46    

mettons
 
octet machin
int bitvalue
int bitposition
 
si bitvalue= 1
machin = machin | (1<<bitPosition)
sinon
machin = machin & ^(1<<bitPosition)
 
le ^ tu le fais en asm via neg
 
 
 

Reply

Marsh Posté le 27-06-2003 à 11:27:24    

allez hop, un petit source bien rapide et bien pipeliné !
 

Code :
  1. MACRO SETBIT(chaine, bitposition, bitvalue)
  2.      mov cl, bitposition
  3.      mov ah, 1
  4.      mov al, 1
  5.      sub ah, bitvalue
  6.      shl al, cl
  7.      xor ah, chaine
  8.      and ah, al
  9.      xor chaine, ah
  10. ENDM



---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 27-06-2003 à 17:11:34    

merci harkonnen :jap:
decidement le jour ou tu disparaitras de ce forum, l'assembleur perdra quelqu'un de très doué !


---------------
Bougredane et bougre d'andouille ne font qu'un !
Reply

Marsh Posté le 27-06-2003 à 17:16:29    

laisse tomber le cirage petit, ça marche pas avec moi


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 27-06-2003 à 18:11:37    

chrisbk a écrit :

mettons
 
octet machin
int bitvalue
int bitposition
 
si bitvalue= 1
machin = machin | (1<<bitPosition)
sinon
machin = machin & ^(1<<bitPosition)
 
le ^ tu le fais en asm via neg


 
tu voulais pas plutôt dire ~ à la place de ^ ?  :sarcastic:


---------------
last.fm
Reply

Marsh Posté le 28-06-2003 à 14:13:06    

theShOcKwAvE a écrit :


 
tu voulais pas plutôt dire ~ à la place de ^ ?  :sarcastic:
 


 
Oué ca va hein ? :O

Reply

Marsh Posté le 20-04-2004 à 23:38:15    

Harkonen> Juste pour le fun...
 
En fait il y a quelques problèmes dans ton code...

Code :
  1. mov cl, bitposition //U... OK
  2. mov ah, 1 //V... OK
  3. mov al, 1 //U...OK
  4. sub ah, bitvalue //V...Attention sur certains cpu la lecture de la mémoire n'est pas paralélisation sur V ou pose de problème
  5. shl al, cl //U...OK (mais 2 cycles au total)
  6. xor ah, chaine //V...Idem que plus haut
  7. and ah, al //U...OK
  8. xor chaine, ah //V...WAR ! 1 cycle de pénalité. + 1 cycles de plus car on fait un Read-Modify-Write de chaine (read passe dans le pipe pour ne faire qu'un cycle de plus !)


Total... 7 cycles... A la deuxième exécution. (10 cycles à la première)
 
Ensuite il y a une erreur, ton code génère un problème sur le bit 0.
 
Je propose un code un peu différent (plus lisible également)

Code :
  1. mov cl, bitposition
  2. mov al, bitvalue
  3. shl al, cl
  4. mov dl, chaine
  5. or dl, al
  6. nop
  7. mov chaine, dl


Total... 5 cycles... (8 cycles à la première exécution)
 
On peut pousser à 5 cycles avec un WAR... (et 6 cycles à la première exécution)

Code :
  1. mov cl, bitposition
  2. mov dl, chaine
  3. shl bitvalue, cl
  4. or dl, bitvalue //WAR
  5. mov chaine, dl


 
Faut faire des concours pour le fun...
 
PS:Le code le plus rapide n'existe pas !


Message édité par christophe_d13 le 20-04-2004 à 23:42:02
Reply

Marsh Posté le 21-04-2004 à 05:03:47    

surtout qu'avec les moteurs out of order des CPUs récents, la notion de pipe U & V tombe pas mal à l'eau...
 
et pi ton code, il marche que si tu veux mettre un bit à un...

Reply

Marsh Posté le 21-04-2004 à 10:34:50    

Tout à fait exact !
Bon j'en rajoute une couche...
 

Code :
  1. mov ecx, bitposition
  2. mov eax, 0xFEFF0000
  3. mov al, bitvalue
  4. add cl, 8
  5. rol eax, cl
  6. mov dl, chaine
  7. and dl, al
  8. or dl, ah


Total... 5 cycles à la seconde exécution... (9 cycles pour la première exécution)
 
A noter que bitposition doit aller de 0 à 7 si cela dépasse, cela ne marche plus.

Reply

Marsh Posté le 21-04-2004 à 10:34:50   

Reply

Marsh Posté le 21-04-2004 à 11:00:29    

up d'un topic vieux de 10 mois, est-ce vraiment utile?


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 21-04-2004 à 11:14:09    

drashe> Dans 10 mois, un autre optimiseur sortira un code encore plus rapide...
 
Au lieu de faire des programmes lourds et lents, les 99% des programmeurs devraient plutôt faire des programmes rapides comme le premier Quake ! Un must du genre.
 
A la place de cela, on te dit : "c'est lent ? alors il faut changer votre processeur, votre mémoire..."

Reply

Marsh Posté le 21-04-2004 à 11:15:36    

je connais le refrain, mon chef de projet me le chante régulièrement [:kiki] (et bien sûr, je suis contre, sinon je ne fréquenterais pas les topics ASM ;))
 
non je remarquais juste que tu uppais beaucoup de vieux topics ASM, ce qui n'est pas forcément bien vu ici ;)


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
Reply

Marsh Posté le 21-04-2004 à 13:52:39    

de mémoire les ror/rol c'est mal naon ?

Reply

Marsh Posté le 21-04-2004 à 14:24:15    

drasche> Ah bon ! Ok, je m'en souviendrais. Pourtant, il y a pas mal de réponses.
bjone>Les ror/rol c'est mal ??? Soit plus clair.

Reply

Marsh Posté le 21-04-2004 à 14:52:32    

il me semble que le coût en cycles des ror/rol est variable car dépendant du décalage.... (itération dégeu en interne)
 
mais je peux me tromper... (ou alors c'est un autre blem, je dis ça de mémoire)


Message édité par bjone le 21-04-2004 à 14:59:03
Reply

Marsh Posté le 21-04-2004 à 14:58:49    

C'était peut-être vrai (je ne m'en souvient plus) pour les anciens procs jqu'au 386 mais à partir du 486, il n'y a pas ce genre de problème.

Reply

Marsh Posté le 21-04-2004 à 15:01:38    

autant pour moi c'esr RCR RCL qui semble plus pénalisant...

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed