Discussion :

[Flo.]

Bonjour,

je code (du moins j'essaie) en xmmx sous linux via gcc.

L'instruction movdqa ("a" pour "aligned") permet de faire des transferts rapides de buffers à registres xmmx. Ces buffers sont censés être alignés sur 16 bits. S'ils ne le sont pas, le movdqa fait planter l'appli. Pour travailler sans se soucier de l'alignement du buffer, on peut alors utiliser "movdqu" ("u" pour "unaligned"), mais c'est beaucoup moins rapide.

Sur internet, j'ai trouvé ce bout de code pour aligner les buffers d'unsigned char. Il marche sous linux (je peux utiliser "movdqa") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// on doit ajouter 16 à la taille originale du tableau 
// donc si je veux travailler avec un buffer de 320*256, je doit créer un buffer de 320*256+16
unsigned char unalignedBuffer[320 * 256 + 16];
 
// on crée un pointeur sur le tableau initialisé qui pointe sur une zone alignée du tableau précédent
unsigned char * alignedBuffer = (unsigned char *)(((long)unalignedBuffer + 15) & (~0x0F));

Cependant, je comprends pas en quoi cette opération permet de récupèrer un pointeur sur une zone alignée.

Par ailleurs, lorsque j'essaie d'adapter ce code sous Windows (borland c++ builder ou visual .NET c++), ça ne marche pas car je ne peux pas utiliser l'instruction "movdqa". C'est peut-être lié au fait qu'ils utilisent pas la même syntaxe assembleur. Je sais pas

Je serais vraiment content de pouvoir avoir une réponse à ces questions.

Merci. A+.

Flo.

[Flo.]

Je voudrais juste rajouter un complément d'informations.

Sous dev-cpp, l'alignement semble fonctionner. Et dev-cpp tout comme gcc utilise la même syntaxe assembleur AT&T au contraire de Borland et Visual qui en utilisent une autre (je sais plus comment elle s'appelle).

Serait-ce possible que le code fonctionne seulement pour les compilo qui utilisent la syntaxe assembleur AT&T ?

Et dans ce cas comment, transposer le code pour aligner les buffers dans l'autre cas ?

A+

Flo.

[Flo.]

Salut,

j'ai un peu avancé mais ça reste encore flou.

Déjà "aligner un buffer sur 16 bytes" semble vouloir dire obtenir une adresse de pointeur (je parle de long là) divisible par 16.

J'ai compris en quoi le code permettait d'obtenir l'addresse divisible par 16 dans l'intervalle d'addresses [unalignedBuffer; unalignedBuffer + 15].

Par contre pourquoi aligner sur 16 bytes ? Je suppose que c'est lié au fait qu'en xmmx on a accès a 16 registres xmmx de 1 byte chacun (1 octet).

Du coup si mon hypothèse sur l'alignement est juste, si on doit obligatoirement aligner les buffers sur 16 bytes pour pas crasher l'appli avec un movdqa, ça sous-entend que les données (les bytes) sont rangés en mémoire dans un ordre bien précis comme sur des segments de 16 octets (segment dont le 1er byte a une adresse divisible par 16). Et du coup, pour charger 16 bytes à cheval sur 2 segments il doit falloir faire un traitement supplémentaire que prendre 16 bytes sur le même segment.

Est-ce que c'est le cas ? Est-ce qu'en mémoire les données sont arrangés sur des "segments" de 16 octets ?

Et est-ce que ça dépend du systeme d'exploitation puisque mon code marche avec certitude sous linux et crashe sous windows (bcb et visual).

Flo.