6
votes

Sur x86 si [MEM] n'est pas aligné 32 bits, peut "verrouiller Inc [Mem]" fonctionne toujours bien?

sur X86, si MEM est aligné 32 bits, l'opération MOV est garantie d'être atomique.

Si [MEM] n'est pas aligné 32 bits, peut LOCK INC [MEM] SILL fonctionne bien?

Travail bien: Fournissez à l'atomicité et ne pas obtenir de valeur partielle.


2 commentaires

Par "bien travailler", vous voulez dire, cela fournit-il de l'atomicité? Ou juste si cela augmente?


Travailler bien: Fournir de l'atomicité et ne pas obtenir de valeur partielle.


3 Réponses :


8
votes

the Intel Instruction Ensemble de référence pour X86 et X64 mentionne rien des exigences d'alignement de l'instruction INC. Tout ce qu'il dit en référence à verrouillage est:

Cette instruction peut être utilisée avec un préfixe de verrouillage permettre aux instructions d'être exécutées atomiquement.

Le verrouillage LOCK PREFIX Documentation STATS:

L'intégrité du préfixe de verrouillage n'est pas affectée par l'alignement du champ de mémoire. Le verrouillage de la mémoire est observé pour des champs arbitrairement malalignés.


9 commentaires

Je ne vois pas non plus rien sur les exigences d'alignement pour l'instruction MOV. Mais MOV est affecté par un désalignement.


Comment MOV affecté par un désalignement? Il lit / écrit avec succès les données indépendamment de l'alginment.


Une réponse très précise. Cependant, comme @vince mentionné, MOV est également garanti de travailler pour une adresse non alignée, mais il y a une pénalité. Je soupçonne que l'utilisation d'une sémantique verrouillage sur une adresse non alignée est similaire, avec des complications potentiellement plus grandes.


L'OP a demandé si les instructions "fonctionnent bien". Et qu'ils font.


Voir Volume 3 8.1.1 Dans le manuel du développeur de logiciels: lecture ou écrire un double mot d'alignement sur une frontière 32 bits


Lisez "Comment résoudre les insectes d'accès mémoire simultanément malaligné": logiciel .Intel.com / fr-US / Forums / showthread.php? T = 7 5386 Il montre le problème de travail réel à propos de MOV


"Accès non aligné 16-, 32- et 64 bits à la mémoire mise en cache qui correspond à une ligne de cache" sera toujours effectuée atomiquement. Mais, en même temps, il est indiqué "Toutefois, les accès des données non alignés ont sérieusement une incidence sur la performance du processeur et devraient être évitées". --- Donc, je ne suis certainement pas en désaccord avec quiconque que les opérations non alignées devraient être évitées. Je déclare juste que les instructions seront exécuteront comme prévu.


Votre LIGNED LINE concerne la ligne de cache. Je dis la ligne ci-dessus ligne: la lecture ou l'écriture d'un double mot d'alignement sur une frontière 32 bits sera toujours effectuée atomiquement. Il indique que l'accès à un double mot-mot n'est pas aligné sur la limite 32 bits ne sera pas.


Si l'adresse d'un double mot (opérande 32 bits) n'est pas alignée sur une limite de 32 bits, alors il pourrait ne pas être fait atomiquement, cela dépend de la limite de la ligne de cache ou non. S'il est aligné, le manuel indique catégoriquement qu'il sera atomique. Notez que quelque 128 bits se déplace vers / à partir de la mémoire doit être aligné être aligné ou que vous avez une faute ... leur mnémonic indique que: Par exemple, MOVDQA est une charge / magasin SSE (MOV) d'un double quadwatwwword (DQ) dont l'adresse doit être alignée (a), donc le nom Movdqa.



2
votes

Le préfixe de verrouillage fournira une atomicité pour un accès à la mémoire non alignée. Sur les systèmes QPI, cela pourrait être très lent. Voir cet article sur le site Web d'Intel:

Comment résoudre des bugs d'accès à la mémoire simultanément mal alignée

http://software.intel.com/fr- US / Forums / Showthread.php? T = 75386


2 commentaires

bonne réponse. S'il vous plaît aider à répondre à une autre question de "Jonathon Reinhart".


Je ne suis pas sûr de ce que le problème est, ou de ce que nous discutons. Je pense que nous convenons tous que a) les instructions fonctionneront correctement sans distinction d'alignement. b) Les accès non alignés doivent être évités pour des raisons de performance.



0
votes

Bien que le matériel soit bien avec des accès non alignés, la mise en oeuvre du code peut s'appuyer sur voler les basses bits 2 ou 3 du pointeur (toujours zéro pour des pointeurs alignés de 32 ou 64 bits respectivement).

Par exemple, la fonction (Win32) InterlockedPushsList ne stocke pas les basses basses 2 ou 3 bits du pointeur, de sorte que toute tentative de poussée ou de pop qu'un objet non aligné ne fonctionnera pas comme prévu. Il est courant que le code sans verrouillage, de cramner des informations supplémentaires dans un objet de pointeur. La plupart du temps, ce n'est pas un problème cependant.

Les processeurs d'Intel ont toujours eu d'excellentes performances d'accès mal alignées. Sur le Néhalem (Core I7), ils sont allés jusqu'à présent: tout accès mal aligné entièrement au sein d'une ligne de cache n'a aucune pénalité et des accès mal alignés qui croiser une limite de ligne de cache ont une pénalité moyenne de 4,5 cycles - très petites.


0 commentaires