Analyse des codes C

Question

Voici la fonction que je suis en train d'écrire sur la machine linux 64 bits.

void myfunc(unsigned char* arr) //array of 8 bytes is passed by reference
{
   unsigned long a = 0; //8 bytes
   unsigned char* LL = (unsigned char*) &a;

   LL[0] = arr[6];
   LL[1] = arr[3];
   LL[2] = arr[1];
   LL[3] = arr[7];
   LL[4] = arr[5];
   LL[5] = arr[4];
   LL[6] = arr[0];
   LL[7] = arr[2];
}

Maintenant, mes questions sont:

1. variable « a » être stocké dans un registre afin que Il ne sera pas accessible encore et encore de RAM ou chache?
2. travail sur architecture 64 bits, dois-je supposer que array « arr » sera stocké dans un registre que sont stockés dans un registre des paramètres de fonctions en arc 64 bits?
3. Quelle est l'efficacité pointeur coulée de type? je suppose qu'il devrait être inefficace du tout?

Toute aide serait appriciated.

Cordialement

Answer 1

1. a ne peut pas être stocké dans un registre, que vous avez pris son adresse. (Valdo souligne à juste titre qu'un compilateur vraiment intelligent peut optimize le tableau des accès dans les opérations de bits et congé a dans un registre, mais je ne l'ai jamais vu un compilateur faire, et je ne suis pas sûr que ce finirais étant plus rapide).
2. arr (le pointeur lui-même) est stocké dans un registre (%edi, sur amd64). contenu du tableau sont en mémoire.
3. coulée de type pointeur par lui-même génère souvent pas de code du tout. Cependant, faire des choses stupides avec des moulages de type peut conduire à un code très inefficace, ou même le code dont le comportement est indéfini.

Il semble que vous essayez de permuter les octets dans un tableau, puis les fourrer dans un certain nombre, et le code de la machine génère votre exemple est pas très mauvais pour ça. La suggestion de David à changement d'utilisation et le masque des opérations est bonne place (cela évitera aussi des problèmes si votre code doit jamais fonctionner sur une machine big-endian), et il y a aussi les instructions vecteur de permuter SSE, mais je leur ai entendu sont un genre d'une douleur à utiliser.

Par ailleurs, vous devez faire le type de retour de votre exemple fonction soit unsigned long et mis return a; à la toute fin; alors vous pouvez utiliser gcc -O2 -S et voir exactement ce que vous obtenez de la compilation. Sans le changement de a de retour, GCC allègrement optimize loin le corps de la fonction, car il n'a pas à l'extérieur des effets secondaires visibles.

Answer 2

Vous pourriez faire mieux utiliser changement explicite et masque des instructions pour ce faire, au lieu d'utiliser l'indexation de tableau.

Les opérations de tableau vont rendre plus difficile pour le compilateur d'utiliser des registres pour cela, car il n'y a généralement pas d'instructions qui font des choses comme « charge 8 bits du 3ème octet du registre A ». (Un compilateur optimisation peut figure que il est possible de le faire avec des changements / masques, mais je ne sais pas comment probable est).

Answer 3

1. La question de savoir si la a variable sera stockée dans le registre est une question d'optimisation. Comme il n'y a pas volatile modificateur à mon humble avis un compilateur intelligent faire.

2. Il est une question de la convention d'appel. Si, par convention, un seul paramètre de pointeur est transféré dans un registre -. Ainsi sera arr

3. coulée de type pointeur ne constitue pas une opération qui interprète CPU. Il n'y a pas de code généré pour elle. Il vient de l'information pour le compilateur de ce que tu veux dire.

(En fait, le fait parfois couler des produits du code supplémentaire, mais cela est lié à l'héritage multiple et polymorphisme)

Answer 4

dépend de votre niveau d'optimisation. Vous pouvez examiner l'assemblée pour répondre à vos questions. Avec gcc, utilisez le drapeau "-S".

gcc -S -O0 -o /tmp/xx-O0.s /tmp/xx.c
gcc -S -O3 -o /tmp/xx-O3.s /tmp/xx.c

L'ensemble généré est complètement différent. (Assurez-vous de faire le changement de return a; suggéré par Zack .)

Voir aussi ce message pour obtenir des conseils sur la façon de générer un mélange c / inscription assemblage (qui devient rapidement inutilisable avec optimisation).