Selon la page Wikipedia défaut de segmentation , une erreur de bus peut être causé par un accès à la mémoire non alignée. L'article donne un exemple sur la manière de déclencher une erreur de bus. Dans l'exemple, nous devons activer la vérification d'alignement de voir l'erreur de bus. Et si nous désactivons une telle vérification d'alignement?
Le programme semble fonctionner correctement. J'ai un programme d'accès à un programme de mémoire non alignée fréquemment, et il est utilisé par assez de personnes, mais personne ne rapporte des erreurs de bus ni d'autres résultats étranges pour moi. Si nous désactivons la vérification d'alignement, quel est l'effet secondaire de la mémoire non alignée?
plates-formes: je travaille sur x86 / x86-64 . J'ai également essayé mon programme en la compilant avec "GCC -arch PPC" sur un Mac et cela fonctionne correctement.
3 Réponses :
Il peut être significativement plus lent d'accéder à la mémoire non alignée (comme dans, plusieurs fois plus lentement).
Toutes les plates-formes ne supportent même pas l'accès non aligné - X86 et X64, mais IA64 (Itanium) ne le fait pas, par exemple.
Un compilateur peut émuler accès non aligné (VC ++ le fait que pour les pointeurs déclarés sous le nom __ non aligné sur ia64, par exemple) - en insérant des contrôles supplémentaires pour détecter les contrôles non alignés. cas, et chargement / stocker des parties de l'objet qui chevauchent la limite d'alignement séparément. Cela est encore plus lent que l'accès non aligné sur les plates-formes qui le soutiennent de manière native.
Merci. Peu d'utilisateurs de mon programme fonctionnent sur l'IA64. Peut-être que c'est pourquoi je n'ai pas reçu de rapport de bogue.
Vous ajoutez également # 4 qu'un système d'exploitation peut imiter l'accès non aligné ONBehal d'une application en attrapant l'exception du processeur et en la fixant (genre de ce qui se passe pour une faute de page). Ceci est plus lent que le compilateur Perofrming Fix d'alinéa non aligné dans le code généré. Windows peut supporter cela en IA64.
Cette réponse a été référencée dans le blog post Alignement des données pour la vitesse: mythe ou réalité? .
Cette réponse pourrait faire avec d'autres spécificités. E.G., l'alignement des données est pertinent sur les limites 32/64 bits pour les opérations scalaires et les limites de 128 bits pour les opérations SIMD sur X86. Plus important encore, vous voudrez peut-être souligner que le coût le plus important est pour une opération pour éviter les lignes de cache
Il y a même un exemple d'exemple de données non alignées utiles pour pousser autant de choses dans le cache de la CPU pour éviter le cache Missess: Danluu .Com / 3C-Conflict Dommage Dommage Il n'y a pas de section de commentaires là-bas, car j'aimerais entendre ce que les autres pensent à cela. Voudrais tester cela moi-même à un moment donné. Et bien sûr, il s'agit de l'architecture du processeur dépendante.
J'ai changé "il est significativement plus lent" de "ce qui peut être" ... ", comme la pénalité de vitesse dépend de nombreux facteurs, parmi lesquels le type de processeur et les effets de cache.
@leetnightshade L'article est très intéressant et utile. Mais comme je le vois, cela ne parle pas de données non alignées dans le sens de l'alignement lié à la taille de la lecture. Il parle d'alignement lié au cache qui se produit dans des bits d'adresse quelque peu plus élevés. Pour visualiser, l'adresse 32 bits est composée de: TTTT TTTT TTTT TTTT TTTT SSSS SSXX XYYY, puis la question actuelle ne parle que de y et rien d'autre. Personne ne se soucie de parler de X et T, et l'article très intéressant que vous vous référez uniquement à propos de S. Juste pour un commentaire supplémentaire, la longueur des bits de S dépend de la taille de cache et du niveau de cache bien sûr.
Cela dépend beaucoup de l'architecture de la puce. x86 et POWER SONT TRÈS PARTOIR, SPARC, ITANIUM ET VAX, différentes exceptions.
Cela dépend en effet du processeur. J'ai récemment travaillé sur un DSP qui procédera volontiers à l'aide de l'adresse de mémoire alignée la plus proche lorsqu'il est invité à fonctionner sur un non aligné. Déboguer que , vous avez perverti de la mémoire non alignée pour accéder à une personne.
En effet, pourquoi se déranger même en regardant ces derniers bits du tout - les hommes réels savent ce qu'ils font, de toute façon :) D'autre part, ce serait une architecture commode d'utiliser des pointeurs marqués, si vous utilisez les bits ignorés pour La balise ...
@Pavel: Considérons l'interfonctionnement du bras / du pouce. Le LSB de l'adresse "d'une instruction indique si la CPU doit entrer en mode pouce (1) ou le mode Bras (0) avant d'exécuter le code de cette adresse. De toute façon, les octets réels de l'instruction cible sont situés en mémoire à l'adresse et ~ 1, il s'agit simplement de copier une valeur pour le compteur de programme potentiellement commutation en mode ainsi que le saut
Considérez 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.
Je pense que vous avez une erreur d'orthographe - votre troisième déclaration référence u16temp variable, où est sa déclaration? Je ne vois que u8temp .
Quelle est la plate-forme sur laquelle vous travaillez ??
Pavel Minaev répond en grande partie à ma question. Je travaille sur x86 / x86_64. J'ai essayé mon programme en la compilant avec "GCC -ARCH PPC" sur Mac et fonctionne correctement.
Notez que l'accès à la mémoire non alignée (en fait, même l'affectation du pointeur) est un comportement indéfini selon la norme C - un compilateur conforme est donc autorisé à faire n'importe quoi si vous le faites (bien que tous les compilateurs ne le feront pas liberté).
Connexes: violation
alignoof (t) est un comportement non défini et peut causer des problèmes du monde réel même sur x86, par exemple lors de la vectorisation automatique du compilateur, peut supposer qu'une limite d'alignement de 16 octets est un nombre total decourt S Suivez: Pourquoi l'accès n'a pas aligné à la mémoire MMAP'ed parfois Segfault sur AMD64?