Discussion :

[hbx360]

Bonjour, j'aimerai comprendre dans le code suivant à la ligne 4 quand ont fais les décalages, par exemple
(nTmp & 0xFF) << 8) est-ce que l'on travail toujours sur la variable nTmp à son adresse ou bien (nTmp & 0xFF) se trouve tel à un autre endroit de la mémoire même si cela me semble improbable car sa obligerai le compilateur à alloué implicitement de la mémoire à un autre endroit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
uint8_t *pPtr = malloc(sizeof(uint8_t)*2);
pPtr[0] = 0; pPtr[1] = 1;
uint32_t  nTmp = *(uint16_t *)pPtr;
nTmp = (((nTmp & 0xFF) << 8) | ((nTmp & 0xFF00) >> 8));

[WhiteCrow]

Bonjour,
alors déjà il faut se rendre compte qu'un compilateur n'est plus un simple traducteur «mot à mot» de C en code machine. Un compilo c'est bien plus intelligent que ça de nos jours. Pour t'en rendre compte tu peux essayer tes codes sur godbolt, l'explorateur de compilateurs.

Tu remarqueras que les compilos récents ne feront rien avec ton à moins d'utiliser le résultat ; tu pourras remarquer que si le compilateur peut au moment de la compilation déterminer la valeur du résultat il le fera et au runtime tu n'auras qu'un affichage de la valeur (genre option -O3).
Il se peut aussi (genre option -O0) qu'il reconnaisse que tu veux échanger les octets de poids forts et faibles d'un short … et qu'il le fasse sans faire aucun décalage …

Bref, ta question est bonne mais la réponse dépend de tellement de paramètres qu'il t'est bien plus simple de tester différents compilos en différentes versions pour différentes plateformes avec différentes options pour en voir le résultat

Bonne exploration

[Bousk]

Est-ce que quand tu écris nTmp + 3 tu travailles sur nTmp ?
Non. Et les opérateurs de bit ne sont pas plus magiques et opèrent de la même manière.

https://c.developpez.com/faq/?page=L...-operateurs-gt
https://c.developpez.com/faq/?page=L...signifie-E1-E2
https://c.developpez.com/faq/?page=L...signifie-E1-E2

[Sve@r]

Bonjour

Bonjour, j'aimerai comprendre dans le code suivant à la ligne 4 quand ont fais les décalages, par exemple
(nTmp & 0xFF) << 8) est-ce que l'on travail toujours sur la variable nTmp à son adresse ou bien (nTmp & 0xFF) se trouve tel à un autre endroit de la mémoire même si cela me semble improbable car sa obligerai le compilateur à alloué implicitement de la mémoire à un autre endroit.

Tu ne comprends pas ce qui se passe, du coups ta question n'a aucun sens. nTmp & 0x FF ne se trouve pas "ailleurs" dans la mémoire, nTmp c'est une variable, donc qui ne se trouve qu'à un endroit dans la mémoire, rien d'autre.

Il se trouve maintenant que nTmp récupère la valeur de ce qu'il y a à l'adresse "pPtr", ok. Et alors? Qu'est-ce que cela change au point précédent? Rien. nTmp reste une variable qui vient de récupérer une valeur comme elle aurait pu en récupérer tant d'autres.

Et ensuite tu modifies la valeur de nTmp, ok tu en as le droit. Et donc qu'est-ce que ça change? Rien. Qu'il y ait une valeur ou une autre...

Les variables ce sont des cases et tu y mets les valeurs que tu veux. Si ces valeurs ont un sens tant mieux sinon tant pis, c'est juste toi que ça concerne.

[Bktero]

Il se trouve maintenant que nTmp contient l'adresse d'une autre variable de ton code, ok.

Si je lis bien le code, nTmp contient pas une adresse, car la partie droite commence par une étoile de déréférencement (et en plus il n'est pas déclaré comme pointeur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
uint32_t  nTmp = *(uint16_t *)pPtr;
                 ^

Bonjour, j'aimerai comprendre dans le code suivant à la ligne 4 quand ont fais les décalages

As-tu déjà bien compris les 3 lignes d'avant ?

1. tu alloues de l'espace pour 2 entiers de 8 bits, qui seront côté à côté quelque part dans la mémoire
2. tu affectes des valeurs à ces 2 entiers (à 0 et 1)
3. tu castes le pointeur pour obtenir un pointeur vers un entier de 16 bits et tu mets la valeur pointée dans un entier de 32 bits

Ainsi, nTmp contient ces 2 octets en poids faible, l'un à 1 et l'autre à 0. Les 16 bits de poids fort sont en tout logique à 0 aussi.

Enfin, ligne 4, tu prends les bits de poids faibles et tu les décales de 8, les bits de poids et tu les décales de 8 dans l'autre sens, tu les assembles avec | et tu les remets dans nTmp. En gros, tu as inversé les 2 octets de poids faibles.

(nTmp & 0xFF) << 8) est-ce que l'on travail toujours sur la variable nTmp à son adresse ou bien (nTmp & 0xFF) se trouve tel à un autre endroit de la mémoire même si cela me semble improbable car sa obligerai le compilateur à alloué implicitement de la mémoire à un autre endroit.

Je ne pense pas que tu puisses le deviner sans regarder le code assembleur généré par ton compilateur (ça dépend des options, du CPU, de la version du compilateur, etc). On peut s'en douter avec l'expérience et la logique, mais je ne crois que ça soit normé par le langage. En toute logique, malloc() va allouer de la mémoire sur le tas. Les autres variables vont être créées sur la pile, mais il est aussi possible qu'elles ne vivent que dans des registres du processeur, sans utiliser la pile.

[Sve@r]

Si je lis bien le code, nTmp contient pas une adresse, car la partie droite commence par une étoile de déréférencement (et en plus il n'est pas déclaré comme pointeur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
uint32_t  nTmp = *(uint16_t *)pPtr;
                 ^

Ah oui. J'ai lu trop vite. Je pensais que nTmp contenait une adresse mais en fait c'est encore plus simple, il contient une bête valeur.
Ok, j'ai corrigé.

[Guesset]

Bonjour,

Hors les éléments très explicites de WhiteCrow, si nous sommes dans un cas où le compilateur doit générer un code (non pré-calculable et dont le résultat est utilisé), il n'utilisera pas de décalage mais plutôt un code assembleur de type :

Code ASM :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
mov ah,        [ptr]
mov al,        [ptr+1]
mov word[ptr], ax

Il n'y a pas de gain à faire une seule lecture (genre mov dx, [ptr]) car les caches font leur travail. Le compilateur peut aussi utiliser les instructions de brassage d'octets du SSE mais cela ne semble pas valable ici.

Il est toujours intéressant de regarder le code assembleur généré. On y trouve des choses très futées et d'autres beaucoup moins.

Entre compilateur et CPU, c'est l'escalade du glaive et du bouclier. Les compilateurs savent très bien optimiser l'usage des instructions élémentaires mais les CPU se dotent d'instructions nouvelles qui sont de moins en moins élémentaires. Aussi, le principe du simple code pour de nombreuses instructions assembleur à optimiser se trouve mis à mal quand une seule instruction assembleur correspond à (relativement) de nombreuses lignes de code.

Salutations

[hbx360]

Merci pour tous vos explications et renseignements.

@Bousk merci pour les liens ; le 1 je l'ai vue mais ne mas pas apporté la réponse que je cherchais.
Pour le 2 il est dis : "On dit qu'on a masqué c1 avec c2. On appelle ça (c2) un masque car il permet de cacher (masquer) certains bits de c1 (cacher signifie mettre à zéro)."

Est-ce que cela veut dire qu'on masque juste les bits de la variable sans les mettre définitivement à 0 tant qu'on ne fait pas une assignation sur la même variable ?
Donc faire c1 = c1 & c2

@Sve@r ça m'intéresse de savoir comment ça fonctionne.

@Bktero oui je pense avoir bien compris les décalages et les lignes que je vous ai fourni, après c'est vraiment dans la subtilité/détail que je cherche à comprendre.

Après sans doute que c'est dans l'optimisation fait par le compilateur que les choses se passe comme l'explique WhiteCrow.

Dans cette exemple :

L3 : Je pense que ce résultat doit être stocké temporairement dans la mémoire quelque part pour garder l'intégrité de la variable (nTmp) de départ.

L4 : ici aussi je pense que c'est pareille le compilo sauvegarde le résultat temporairement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
    // Je suis en Little Endian.
    L1         0100 0000 1000 0000 0000 0000 0000 0000 
    L2 & 0xFF  1111 1111 0000 0000 0000 0000 0000 0000
    ---------------------------------------------------
    L3 << 8    0100 0000 0000 0000 0000 0000 0000 0000 
    ---------------------------------------------------
    L4         0000 0000 0100 0000 0000 0000 0000 0000