alignement du pointeur dans libjpeg

Question

De jmorecfg.h:

#define PACK_TWO_PIXELS(l,r) ((r<<16) | l) 
#define PACK_NEED_ALIGNMENT(ptr) (((int)(ptr))&3) 
#define WRITE_TWO_PIXELS(addr, pixels) do {  \ 
     ((INT16*)(addr))[0] = (pixels);  \ 
     ((INT16*)(addr))[1] = (pixels)>>16; \ 
    } while(0) 
#define WRITE_TWO_ALIGNED_PIXELS(addr, pixels) ((*(INT32*)(addr)) = pixels 

Quelqu'un peut-il expliquer la différence entre WRITE_TWO_PIXELS et WRITE_TWO_ALIGNED_PIXELS? Si les pixels sont une pile allouée uint32_t et addr & 3 == 0, ne devraient-ils pas être équivalents?

Merci.

Answer 1

WRITE_TWO_PIXELS et WRITE_TWO_ALIGNED_PIXELS sont équivalents pour les petites machines d'endian mais pas pour l'architecture big endian.

[Exemple modifié: grâce à Steve Jessop]

Soit, pixels = 0x0A0B0C0D

Pour les grandes machines endian, WRITE_TWO_PIXELS fonctionnent comme suit:

--------------------- 
| 0B | 0A | 0D | 0C | 
--------------------- 
    3 2 1 0   <--- addr 

où WRITE_TWO_ALIGNED_PIXELS écriront comme suit:

--------------------- 
| 0D | 0C | 0B | 0A | 
--------------------- 
    3 2 1 0   <--- addr 

Answer 2

Dans les deux macros, le seul alignement important est l'alignement de addr. Comme écrit dans la question, ils sont équivalents si addr est aligné sur 32 bits (ce qui signifie que ses deux bits faibles sont nuls), mais seulement si l'architecture cible est également little-endian.

Sur une machine big-endian, les 16 bits supérieurs de pixels doivent être écrits à (INT16*)(addr))[0] et les 16 bits inférieurs à (INT16*)(addr))[1] pour qu'ils soient équivalents.

Sans vérifier ma copie du code source libjpeg, j'imagine que ces définitions devraient être modifiées dans le cadre du portage de la bibliothèque, ou qu'elles sont déjà protégées par une déclaration d'endianness. Si addr n'est pas aligné sur 32 bits, la macro WRITE_TWO_ALIGNED_PIXELS peut provoquer une exception sur les architectures où l'accès non aligné n'est pas autorisé. Bien sûr, dans certains cas, l'accès non aligné est autorisé, mais il est beaucoup plus coûteux que deux accès alignés plus petits, et sur d'autres architectures, l'accès non aligné est difficile à distinguer de l'accès aligné. Les deux macros existent pour rappeler à l'auteur de la bibliothèque de penser à l'alignement et pour normaliser l'approche de gestion de l'accès désaligné afin qu'il puisse être optimisé lors de la construction pour les plates-formes où cela n'a pas d'importance.