L'accès mémoire non aligné entraîne-t-il toujours des erreurs de bus?

Question

Selon la page Wikipedia Segmentation fault, une erreur de bus peut être causée par un accès mémoire non aligné. L'article donne un exemple sur la façon de déclencher une erreur de bus. Dans l'exemple, nous devons activer la vérification d'alignement pour voir l'erreur de bus. Que faire si nous désactivons une telle vérification d'alignement?

Le programme semble fonctionner correctement. J'ai un accès au programme de la mémoire non alignée fréquemment, et il est utilisé par un certain nombre de personnes, mais personne ne signale les erreurs de bus ou d'autres résultats étranges pour moi. Si nous désactivons la vérification de l'alignement, quel est l'effet secondaire de la mémoire non alignée? Plateformes: Je travaille sur x86/x86-64. J'ai également essayé mon programme en le compilant avec "gcc -arch ppc" sur un Mac et cela fonctionne correctement.

Answer 1

1. Il peut être beaucoup plus lent d'accéder à la mémoire non alignée (comme dans, plusieurs fois plus lent). Toutes les plates-formes ne prennent pas en charge les accès non alignés, par exemple, avec x86 et x64, mais pas avec ia64 (Itanium), par exemple.

2. Un compilateur peut émuler accès non aligné (VC++ fait que pour les pointeurs déclarés comme __unaligned sur ia64, par exemple) - en insérant des contrôles supplémentaires pour détecter le cas non aligné, et le chargement/stockage parties de l'objet qui chevauchent la limite d'alignement séparément. C'est même plus lent que l'accès non aligné sur les plates-formes qui le supportent nativement, cependant.

Answer 2

Cela dépend beaucoup de l'architecture de la puce. x86 et POWER sont très indulgents, Sparc, Itanium et VAX jettent différentes exceptions.

Answer 3

Prenons l'exemple suivant que je viens de tester sur ARM9:

//Addresses  0  1  2 3  4  5  6  7  8 9 
U8 u8Temp[10] = {0x11,0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x00}; 

U32 u32Var; 

u32Var = *((U32*)(u16Temp+1)); // Let's read four bytes starting from 0x22 

// You would expect that here u32Var will have a value of 0x55443322 (assuming we have little endian) 
// But in reallity u32Var will be 0x11443322! 
// This is because we are accessing address which %4 is not 0.