Salut,
 
J'aimerai par exemple passer de 01110001 à 10001110.
C'est à dire que le 1er bit se retrouve en 8ieme position, le 2nd en 7 ieme etc...
J'ai bien réfléchis et a pars faire un algo assez long je vois pas trop (avec des ror, and etc... et surtout en se servant de 2 registres (j'aimerai en avoir qu'un)).
 
Quelqu'un a une idée ?

si ton octet est dans al et que eax est utilisable :
 

 
le résultat est dans ah

Ah oué voila c'est tres long    
Y'a vraiment rien de plus simple ?  
 
EDIT : Merci en tout cas

de rien
long ?
t'as déjà fait du RISC ? ça c'est ce que j'appelle long.
 
Cette boucle est déroulée, enroulé avec un loop ça ferait 6 lignes. C'est pas énorme. Il y a des bonnes méthodes pour inverser les octets d'un WORD ou d'un DWORD, mais pas les bits, ou alors c'est un truc tordu que je connais pas.

Si c'est juste les bits d'un octet, je suggère soit la table de lookup à 256 entrées, soit une table à 16 entrées mais on fait 2 lookup dedans, une fois pour les 4 bits de poids faible et une fois pour ceux de poids fort

C'est à dire ?  

 
Tu crée en mémoire une fois pour toute un tableau à 256 entrées représentant la transformation que tu veux faire. Après il suffit de faire ( exemple en C ) :

Je pense que c'est tres lent ca, vu qu'il y a acces mémoire    
Quelqu'un peut dire a vue d'oeuil si c plus rapide que de faire une boucle en asm (celle de jesus_christ) ?  

Une fois le tableau en cache ce qui n'est vraiment pas difficile pour un tableau de 256 octets, c'est certainement beaucoup plus rapide que la boucle vue ci dessus. Le seul point litigieux serait pour le cas ou le resultat obtenu influe sur la prediction de branchement dans les quelques instructions suivantes.

ouais l'option de kris semble la meilleure, 256 octets ça rentre dans le L1. T'aura un AGI stall à chaque accès mais ça doit être + rapide qu'une boucle qui tourne 8 fois.

 
on peut chippoter un peu et preferer utiliser
rol al,1
rcr ah,1
 
ca evite l'instruction adc, puisque la rotation passe par le carry

Merci  

bien vu !!! ça shift et ajoute le bit de poids faible en une instruction
je mettrai alors

vu que la première rotation ne sert à sortir le bit de poids fort, shift est suffisant et + rapide que la rotation sur la plupart des cpu (tous ?).

exact, rcr ne prend qu'1 cycle (a partir du p1), alors que shl en prend 3
 
bravo!

euh c'est pas le contraire ?

nan d'apres le bouquin, c'est bien "rcr reg,1" qui prend 1 cycle

j'ai vérifié dans mon bouquin (JB Emond) et les deux opérations

prennent toutes les 2 un seul cycle.
Ca serait trop étrange qu'un rotate (peu utilisé) prennent plus de place qu'un shift (très utilisé)

pour quel proc??
j'ai pas le p4
 
atention il faut aussi tenir compte de la mise a jour du reg status,  
d'apres ma doc
rcr met a jour carry et overflow, alors que shl met a jour Overflow, sign,zero, aux carry, parity, et carry
ca vient ptet de là??

Je viens de me creuser la cervelle... ça m'arrive    
 
J'ai donc trouver une autre technique. Celle-ci est beaucoup plus rapide. Donc... (c) Christophe Gossa, Tous droits réservés.
 
En fait on va décomposer l'opération successivement. En 3 étapes :
- Permutation des 2 quartets (2x4 bits)
- Permutation des 4 paire de bits (4x2 bits)
- Permutation finale des 8 bits (8x1 bits)
 
Voici un exemple : On ne verra que la représentation des 8 bits (0 à 7)

 
Total des instructions :
- 6x décalages
- 6x masques (ET)
- 6x OU

hum
je ne vois pas bien ton truc
pour que ca marche tu dois rajouter les masquage des bits inutiles, sinon avec tes OU tu vas avoir des 1 partout

Petit code vite fait pour illustrer avec l'explication...

Résultat sur un Barton :
10 cycles en boucle.
 
On peut dire que le re-ordering du cpu est assez efficace, mais le code est plus efficace pour du 2 canaux que pour le 3 canaux des amd.

je n'ai qu'une chose à dire :  

 
  beau travail
et le programme "classique" il prend combien de cycles??

je débarque peut etre avec mes vieux souvenirs d assembleur zx80 mais.. un XOR ca existe pas sur ASMx86?
 
EDIT: faites pas attention j avais compris autre chose par "inverser les bits d un octet": mettre des O a la place des 1 et des 1 a la place des 0.. j avais pas lu la question en entier.. Je vais dormir

si, mais tu veux le mettre ou??

 
EDIT: faites pas attention j avais compris autre chose par "inverser les bits d un octet": mettre des O a la place des 1 et des 1 a la place des 0.. j avais pas lu la question en entier.. Je vais dormir    

 
pas grave

C'est NOT ca  

Résultat de la comparaison :

25 cycles !
 

24 cycles !
 

10 cycles !
 

3 cycles !
 
Sous forme de mini-tableau
#1 =========================
#2 ========================
#3 ==========
#4 ===
 
Toutes ces mesures sont faites dans une boucle de 1.000.000. Donc le code est dans le cache et se trouve paralélisé.

dans le cas 2 tu n'a pas besoin du "adc ah,0"
mais bon, c'est chippoter
 
c'est clair que la table c'est le mieux si c'est juste avec 256 octets et qu'il y a un traitemnt lourd derriere

prorel> Tout dépend de l'usage. Dans le cas où la routine est appelé assez rarement, ou bien que juste avant le cache est altéré, il faudra choisir la meilleure routine.
Les pénalités sur AthlonXP+nForce2 si les données sont en :  
RAM - >180 cycles
L2 - 20 cycles
L1 - 3 cycles.
 

on peut faire un compromis
 
lancer la premiere fois le prog 1 qui charge la table, et les appels suivants on passe par la table

prorel> Oui, mais si pour les appels suivants la table n'est pas dans L1 ? On passe à 20 cycles !
 
A l'inverse si on sait que l'on parcourera toute la table, on peut faire un software-block-prefetch en lisant simplement les offsets 0, 32, 64, 96... jqà 224 pour un ligne de 32 octets et 0, 64, 128 et 192 pour une ligne de cache de 64 octets.

vi, c'est clair

Il n'y a jamais de meilleures méthodes, juste des compromis.
 
Bonne nuit !      

C'est gentil d'essayer de faire le code le plus optimisé pour ma simple question    

je voudrais pas chipoter mais un rotate 4 sur al dans la méthode de chris (jolie d'ailleurs ) au lieu de la 1ere étape ça serait pas + rapide ?
et puis dans la méthode #2 il n'y a pas de adc, sinon le code est faux.

Bien vu mais bon c'est un premier jet, je n'ai pas cherché à faire le plus rapide. Juste expliquer en ASM ma méthode.
Up> Et puis il fallait vraiment voir les 3 étapes. Mais ceci dit en ajoutant la rotation, on gagne 2 cycles. soit 8 cycles seulement.
Il est encore posible d'améliorer le code... D'après mon analyse je pense que l'on peut tomber le nombre de rotation à 3 à cause de la récurence et il doit être possible de grouper l'étape 1 et 2.
 
Up #2> Et bien c'est fait, 7 cycles seulement, simplement en analyse.
 
Le code et l'explication

 
Aucune optimisation de bas niveau, juste une reflexion sur l'algo.
Donc, 7 cycles.