Version imprimable
Je me demande si quelqu'un connait un moyen de contourner la restriction des instructions SSE qui fait qu'elles ne peuvent travailler que sur des données alignées par 16 octets. Les mov ont bien des versions non-aligné genre movdqa et movdqu, mais toutes les instructions de calcul n'ont qu'une version.
Bon une autre question alors
est-ce que quelqu'un sur le forum a deja utilisé les instructions SSE ?
Oui. Un peu juste pour essayer.
Par contre il n'y a pas moyen de faire autrement, il faut s'assurer que les données soient alignées en mémoire à des adresses correctes.
Dans tous les assembleurs il existe des directives d'alignement des variables.
je sais comment aligner les données merci, mais des fois on a pas le choix, on se retrouve avec des données non alignées. Imagine une image ou chaque pixel est représenté par un octet. Tu alignes le début de l'image sur 16, très bien. Maintenant imagine que tu as un petit carré de 16x16 pixels, et que tu dois comparer ce carré avec tous les carrés possibles contenus dans l'image. Tu commences à comparer aux coordonnées x=0 y=0 dans l'image, tout va bien parce qu'elle est alignée, et ensuite si par exemple tu fais x=1 et y=0, ben ça va plus, c'est plus aligné, car l'adresse que tu vas passer à l'instruction sera [début de l'image+1]
Dans ton exemple tu compare octet/octet donc pas besoin de SSE et donc d'alignement (par contre tu pourrais comparer 4 par 4). N'oublie pas que les SSE sont faîtes pour travailler avec des flottants (de 4 ou 8 octets pour les SSE2) et non pour faire des calcul sur des entiers. .Citation:
Envoyé par Chris_hks
NB:
1- Pour l'égalité, tu doit doit pouvoir arriver à comparer 16/16 avec les SSE (avec PXOR mais après il faut tester un résultat nul de 16 octets...)
2- Les MMX et SSE n'ont pas été faîtes pour les comparaisons dans le sens ou les instruction comme PCMEQB ne modifie pas les flags. Sauf dans le cas de comparaison de flottants (CMPPD,CMPSD..)
A+
Merci pour ta participation AMILIN.
Alors deja, j'ai pas été assez clair pour la comparaison, il n'y a pas vraiment de comparaison proprement dite, les octets sont comparés par soustraction, il y a une instruction toute faite pour ça d'ailleurs : psadbw qui marche en mmx et en sse.
Bien sûr qu'on peut faire des calculs sur des entiers, toutes les instructions mmx sont disponibles avec les registres xmm en sse2.
OK.
Pour ton exemple, tu peut coder de manière différentes selon le x du carré
A+Code:
2
3
4
C'est ce que je fais deja :
si multiple de 16, soustraction SSE
sinon soustraction MMX
vu qu'avec les MMX ya pas de restrictions sur l'alignement. Tu crois que ça pourrait être bénéfique d'utiliser les MMX que sur les multiples de 8 ?
Donc, les données manipulées via MMX doivent être alignée sur 8 octets. L'alignement, n'est pas obligatoire comme sur certaine instructions SSE mais recommandé: l'accès aux données est toujours plus rapide lorsque l'on respecte l'alignement "naturel" (8 octet pour MMX).Citation:
Envoyé par Intel
Et ceci est une règle générale, que ce soit AMD ou Intel (et sûrement pour les autres procs...). Ce problème à toujours existé. Par exemple, sur un 8086, un WORD non-aligné sur une adresse paire est chargé en deux fois depuis la RAM.
Donc:
- WORD -> alignement sur 4 (ie les procs 32 bits n'aime pas les données plus petites qu'un DWORD)
- DWORD -> alignement sur 4
- QWORD -> alignement sur 8
- DQWORD -> alignement sur 16
- TBYTE -> sur 8 ! (pour AMD, pour Intel je ne sais pas)
L'alignement par défault sur un proc 32 bits est donc de 4 octets. Sur 64 bits ce sera 8 octets etc...
A+
oui je sais, mais en fait l'instruction psadbw effectue plusieurs opérations, je pense qu'il vaut mieux utiliser la forme MMX même si les données sont pas alignées. psadbw soustrait les 8 octets de la destination aux 8 octets de la source, fait la valeur absolue de ces 8 soustractions et finalement fait la somme de ces 8 valeurs absolues et stocke le résultat sous forme de word dans la destination. Assez lourd à recréer avec des instructions normales non ? qu'est-ce que t'en penses ?
Effectivement, là je ne vois pas comment faire avec les instructions normales...
As tu réellement besoin de cette somme ? Que fais réellement ton calcul ?
Oh que oui j'en ai absolument besoin, ça s'appelle SAD, sum of absolute difference, ça fait partie d'un algorithme de motion estimation, c'est de la compression video
Alors tu n'as pas le choix... SSE si aligné sur 16 et MMX sinon.
Juste au cas au ça intéresse qqun, en fait ya une solution toute simple, je sais pas pourquoi j'y ai pas pensé avant. Il suffit de mettre toutes les données non-alignées en registre avec des movu et ensuite on travaille que sur les registres
ex :
:)Code:
2
3
4