Décalage de bits et adresse de la variable

Version imprimable

21/02/2022, 19h24
hbx360

Décalage de bits et adresse de la variable
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:

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));
21/02/2022, 22h19
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 :)
21/02/2022, 22h44
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
22/02/2022, 07h02
Sve@r

Bonjour

Citation:

Envoyé par 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.

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.
22/02/2022, 08h50
Bktero
Citation:

Envoyé par Sve@r

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:

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

Envoyé par hbx360

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.

Citation:

Envoyé par hbx360

(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.
22/02/2022, 09h14
Sve@r
Citation:
Envoyé par Bktero

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:

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é.
22/02/2022, 10h26
Guesset

Du code et des codes
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:

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

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:

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

Ou bien...

Bonjour,

Pour le fun (associativité et commutativité du ou exclusif à l'ouvrage).

Code:

1
2
3
4
5
6
uint8_t *p = malloc(sizeof(uint8_t)*2);
p[0] = 0; p[1] = 1;;   // Valeurs initiales nommées p[0]_i et p[1]_i dans les commentaires
 
*p     ^= *(p+1);   // p[0] = p[0]_i xor p[1]_i
*(p+1) ^= *p;       // p[1] = p[1] xor p[0] =  p[1]_i xor (p[0]_i  xor p[1]_i) = p[0]_i = 0
*p     ^= *(p+1);   // p[0] = p[0] xor p[1] = (p[0]_i xor  p[1]_i) xor p[0]_i  = p[1]_i = 1

Pas drôle ? Tant pis :(.

Salutations

22/02/2022, 20h06
Sve@r

Citation:

Envoyé par hbx360

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

Nan mais parce que j'avais mal lu, je pensais que nTmp était un pointeur. Bktero m'a repris.
Mais tu aurais écrit un code un peu plus simple, style int nTmp=123 ça n'aurait rien changé à la question et aurait été moins confusant. Surtout que "adresse de la variable" de ton titre n'entre absolument pas en ligne de compte dans ta question.

Citation:

Envoyé par hbx360

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)."

Oui. C'est à dire qu'on les supprime de la valeur initiale.
Si par exemple t'as une valeur xyz ("x", "y" et "z" représentant chacun un bit pouvant valoir 0 ou 1) et que tu la filtres via un masque de valeur 5 (101 en binaire) cela donnera au final x0z (la valeur "y" a été "masquée").
Cela permet de regrouper plusieurs booléens sur un entier. Exemple les droits Unix sont séparés en R (read=100), W (write=010) et X (exécute=001). Si on prend un fichier qui a le droit 6 (110), alors étant donné que 110 masqué par 100 (droit R) donne 100 et que cette valeur n'est pas 0, cela veut dire que R est présent. Pareil pour W (110 & 010 donne 010 donc pas 0 => W est présent). Mais pour X cela fait 110 & 001 = 000 => X n'est pas présent. Au final le fichier possède le droit R et W mais pas X => on peut le lire et le modifier mais pas l'exécuter.

Citation:

Envoyé par hbx360

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

Oui. Tout calcul est fait en RAM et sera perdu si on ne l'affecte pas quelque part. Si j'écris i+1 cela n'aura aucun intérêt si je ne récupère pas le résultat d'une façon (exemple j=i+1) ou d'une autre (exemple printf("%d\n", i+1)).

Citation:

Envoyé par hbx360

[...]

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 …

[...]

Alors il est bien plus simple pour avoir une réponse de la demander plutôt que de se perdre en conjectures et de «penser que …».

Si tu suis le lien que je t'ai donné tu pourras remarquer que si tu prends comme compilateur clang, que tu choisis une vieux i386 comme processeur cible en compilant en mode 32bit sans optimisations ton code nTmp = (((nTmp & 0xFF) << 8) | ((nTmp & 0xFF00) >> 8)); produira :
Code:

1 2 3 4 5 6 7 8 mov eax, dword ptr [ebp - 8] and eax, 255 shl eax, 8 mov ecx, dword ptr [ebp - 8] and ecx, 65280 shr ecx, 8 or eax, ecx mov dword ptr [ebp - 8], eax
La variable nTmp est sur le stack en ebp-8. On charge le registre eax avec la valeur de la variable (l1), on fait un and $FF (l2) puis on décale à gauche de 8 positions (l3). Ensuite on recharge la valeur de la variable ntmp dans ecx (l4) on la and avec $FF00 (l5) et on la décale à droite de 8 positions (l6). On fait un or sur les deux registres en l7 et on replace la valeur obtenue dans l'emplacement de la variable nTmp en l8.

On peut constater que c'est une traduction mot à mot de C vers l'asm (utilisation des flags -O0 -march=i386 -m32).

Si on reprend ton code, en gardant le même processeur cible et la même option d'optimisation mais qu'on change le compilo de clang vers gcc le code asm produit est légèrement différent :
Code:

1 2 3 4 5 6 7 8 mov eax, DWORD PTR [ebp-16] sal eax, 8 movzx edx, ax mov eax, DWORD PTR [ebp-16] shr eax, 8 movzx eax, al or eax, edx mov DWORD PTR [ebp-16], eax
Si en revanche tu demandes de compiler pour un processeur plus récent (rocketlake) en 64 bits le code est légèrement différent (réordonnancé pour prendre avantage du pipeline) :
Code:

1 2 3 4 5 6 7 mov eax, DWORD PTR [rsp+12] mov edx, DWORD PTR [rsp+12] sal eax, 8 movzx edx, dh movzx eax, ax or eax, edx mov DWORD PTR [rsp+12], eax
etc.

Explore godbolt, tu en apprendras beaucoup … et oublie de penser que l'on peut savoir aisément ce qu'un compilo fait … ou ne fait pas ; quoiqu'il en soit, un compilo bien renseigné donnera toujours un code meilleur que ce que 99% des gens peuvent produire.

23/02/2022, 00h25
foetus
Citation:

Envoyé par hbx360

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 ?

Reprends tes tables de Karnaugh :mrgreen:

Avec 1 opération AND, tu vas extraire 1 ou plusieurs bits. Dans ton cas, ton masque 0x00FF permet de prendre l'octet de poids faible (sur 16 bits) et le masque 0xFF00 permet de prendre l'octet de poids fort (sur 2 octets).
Avec 1 opération OR, on veut tester les drapeaux ("flags" en anglais). 1 exemple, ce sont les valeurs énumérées (avec donc, des valeurs en puissance de 2 : 1, 2, 4, 8, 16, 32, ...)

Citation:

Envoyé par hbx360

@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.

Ton code est ultra trivial :mrgreen:

Tu crées 1 variable de 16 bits avec 1 tableau de 2 octets (que tu ne désalloues pas :whistle:) ... c'est comme le type short.
Tu mets la valeur 256, 0x100 en hexadecimal.
Et avec les décalages et les opérations, tu inverses les octets.
- ((nTmp & 0xFF) << 8) ¹ : tu prends l'octet de poids faible et tu mets en poids fort (tu le déplaces d'1 octet vers la gauche)
- ((nTmp & 0xFF00) >> 8) ² : tu prends l'octet de poids fort et tu mets en poids faible (tu le déplaces d'1 octet vers la droite)
- (¹ | ²) : tu "assembles" le tout
~~Tes masques ne sont pas forcément utiles, mais ils évitent tous les problèmes de bits qui trainent.~~
Édit : les masques sont essentiels

Citation:

Envoyé par hbx360

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

Je ne vois pas la question :weird: mais les opérations logiques (AND, OR, XOR, ...) ne sont que sur des entiers. Sinon le compilateur te le dit.
De toute manière ton code est foireux : les adresses sont en 64 bits et/ ou dépend de la plateforme et les adresses sont "virtuelles" ne peuvent pas être générées "sur la mouche" (on the fly pour la réf.)
23/02/2022, 12h11
Bktero

Citation:

Envoyé par WhiteCrow

Alors il est bien plus simple pour avoir une réponse de la demander plutôt que de se perdre en conjectures et de «penser que …».

Si tu suis le lien que je t'ai donné tu pourras remarquer que si tu prends comme compilateur clang, que tu choisis une vieux i386 comme processeur cible en compilant en mode 32bit sans optimisations ton code

Ca ne sert effectivement à rien deviner ou conjecturer : il faut regarder ce que fait le compilateur ! :plusser:

En revanche, regarder et analyser de l'assembleur sans optimisation, ça ne sert à rien. Le compilateur n'utilise pas vraiment les fonctionnalités du CPU et de son jeu d'instructions. Il faut donc écrire un petit code qui permet de ne pas se faire totalement optimiser et de regarder ce que ça donne au moins en -O1 : https://godbolt.org/z/591z3MTx8 C'est marrant de passer en O2 et de voir que c'est encore différent.
23/02/2022, 15h20
hbx360

Citation:

Envoyé par Sve@r

Nan mais parce que j'avais mal lu

Pas de soucie.

Citation:

Envoyé par Sve@r

Surtout que "adresse de la variable" de ton titre n'entre absolument pas en ligne de compte dans ta question

Bin en fait je ne savais pas comment exprimé ma demande donc mon titre est foireux.

Citation:

Envoyé par WhiteCrow

Alors il est bien plus simple pour avoir une réponse de la demander plutôt que de se perdre en conjectures et de «penser que …».

C'est ce que j'ai fait en ouvrant cette discussion, j'ai posé la question. Après j'ai bien conscience que la façon don je veux exprimé ma demande est pas ouf, j'ai un peu de mal à me faire comprendre.

Citation:

Envoyé par WhiteCrow

Si tu suis le lien que je t'ai donné

Je l'ai fait j'ai rentré mon code j'ai eu les informations en assembleur pareille que toi avec GCC mais je ne comprend pas l'assembleur. Donc merci pour les explications.

Citation:

Envoyé par WhiteCrow

La variable nTmp est sur le stack en ebp-8. On charge le registre eax avec la valeur de la variable (l1), on fait un
and $FF (l2) puis on décale à gauche de 8 positions (l3)

Si on prend cette opération ci-dessus, quand le calcul avec AND est fini le résultat est stocké où ? C'est cela que je cherche à savoir, car si on met le résultat du AND dans la variable nTmp qui est sur la stack en ebp-8 on perd la valeur initial de nTmp donc il faut bien mettre ce résultat quelque part pour évité de modifier la valeur de nTmp puisque :

Citation:

Envoyé par WhiteCrow

Ensuite on recharge la valeur de la variable ntmp dans ecx (l4) ...

Donc comme on réutilise nTmp pour faire le 2e AND on doit garder la valeur initial elle ne doit pas être modifié avant l'assignation.

Citation:

Envoyé par foetus

Ton code est ultra trivial

En fait quand je parle de subtilité/détail c'est juste la question que je pose ci-dessus, pour l'opération nTmp & 0xFF le résultat est mit où ? Si c'est dans la variable nTmp alors on perdra sa valeur de départ, dans un autre endroit de la mémoire ?

Citation:

Envoyé par foetus

Tes masques ne sont pas forcément utiles, mais ils évitent tous les problèmes de bits qui trainent.

Se que j'ai compris des masques c'est que si on en met pas on ne pourra pas avoir le résultat voulu parce que si on fait juste nTmp << 8 on perdra l'information de la variable nTmp puisque la modification sera mis en dure dans nTmp et quand on réutilisera nTmp pour décaler à droite on aura plus la valeur de départ de nTmp.

Citation:

Envoyé par Bktero

...il faut regarder ce que fait le compilateur !

Pour moi le compilateur ne répond pas à ma question posé plus haut i.e où sont mis les résultats des opérations intermédiaire ?

Je modifie mon message pour me répondre en reprenant ce qu'a dit WhiteCrow: "On charge le registre eax avec la valeur de la variable (l1)" Donc si je comprends bien les calcules se font sur le registre eax si qui permet d'avoir les résultats intermédiaire AND et décalage.
23/02/2022, 22h08
WhiteCrow

Bon, si tu cherches un tout petit peu les opcodes x86 tu verras que l'opcode AND fonctionne ainsi :
L'opcode attend deux opérande, la destination et la source, avec la syntaxe utilisée (intel en l'occurence) on écrit AND destination, source. Cette instruction fait un ET bit à bit entre destination et source et stocke le résultat dans destination ⇒ destination = destination AND source.
En gros, le «résultat est stocké dans un registre». Pour «stocker le résultat d'un AND dans un registre» il faut commencer par placer la valeur de nTmp dans ce registre puis de dire avec quelle valeur tu veux faire un AND bit à bit.

Sais-tu ce qu'est un registre ? Comment fonctionne un x86 (en très gros) ? quel est le modèle mémoire de C ? …

Maintenant c'est une façon de faire, il y en a d'autres. On pourrait imaginer un compilateur qui ferait un AND entre deux valeurs dont on donne les adresses. Le choix d'utiliser des registres vient du fait que c'est plus performant et qu'ils sont disponibles à ce moment donné dans le code produit.

Maintenant il y a aussi d'autre architecture où cela sera fait autrement … tout simplement parce que d'autres architectures pourraient proposer un opcode qui fait d'un coup ce que ton code source demande (un peu à la BSWAP du x86).
24/02/2022, 14h54
Bousk

Avant de se soucier de ce que sont les registres etc, tu devrais te concentrer sur comprendre ce qu'est un opérateur binaire, unaire et quand une simple variable est modifiée.:calim2:
Et c'est largement suffisant.
24/02/2022, 17h24
Sve@r

Citation:

Envoyé par hbx360

En fait quand je parle de subtilité/détail c'est juste la question que je pose ci-dessus, pour l'opération nTmp & 0xFF le résultat est mit où ?

L'unité de calcul s'en occupe

Citation:

Envoyé par hbx360

Si c'est dans la variable nTmp alors on perdra sa valeur de départ

Bien évidemment. Tant que tu n'écris pas spécifiquement nTmp=... nTmp ne sera jamais modifié même s'il est utilisé dans un calcul

Citation:

Envoyé par hbx360

Se que j'ai compris des masques c'est que si on en met pas on ne pourra pas avoir le résultat voulu parce que si on fait juste nTmp << 8 on perdra l'information de la variable nTmp

Exact (et c'est vrai quel que soit le calcul)

Citation:

Envoyé par hbx360

puisque la modification sera mis en dure dans nTmp et quand on réutilisera nTmp pour décaler à droite on aura plus la valeur de départ de nTmp.

Il ne faut pas penser en terme "valeur de départ" mais juste en terme de "valeurs à l'instant T". Quand tu écris ntmp=X tu lui mets une valeur X. Si tu écris ensuite ntmp=Y ben tu lui mets une valeur Y et bien évidemment tu perds la valeur X.

Citation:

Envoyé par hbx360

Pour moi le compilateur ne répond pas à ma question posé plus haut i.e où sont mis les résultats des opérations intermédiaire ?

Dans l'UAL (Unité Arithmétique et Logique). Elle a ses propres zones de travail lui permettant de calculer X operateur Y. Et puis au bout du compte, est-ce vraiment important ???
24/02/2022, 18h28
Bktero

Citation:

Envoyé par hbx360

Pour moi le compilateur ne répond pas à ma question posé plus haut i.e où sont mis les résultats des opérations intermédiaire ?

Citation:

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

Euh.... Si tu te demandes si le compilateur alloue de la mémoire, pour après dire que le compilateur ne répond pas à ta question, il va falloir faire le point dans ta tête sur ce que tu cherches à savoir ;)

"où sont mis les résultats des opérations intermédiaire ?" = et bien dans le registre que le compilateur aura choisi d'utiliser (ou sur la pile ou là où le compilateur aura décidé)
24/02/2022, 19h17
foetus
Citation:

Envoyé par hbx360

Se que j'ai compris des masques c'est que si on en met pas on ne pourra pas avoir le résultat voulu parce que si on fait juste nTmp << 8 on perdra l'information de la variable nTmp puisque la modification sera mis en dure dans nTmp et quand on réutilisera nTmp pour décaler à droite on aura plus la valeur de départ de nTmp.

Après test, avec la valeur 256
- (((val & 0xFF) << 8) | ((val & 0xFF00) >> 8)) vaut 1
- ((val << 8) | (val >> 8)) vaut 65537
Justement parce que tes décalages ne sont plus sur 1 octet, mais sur la valeur entière (ton cas 2 octets)
Comme je l'ai dit, tes masques servent juste à extraire 1 seul octet (octet poids fort et octet poids faible)
Et effectivement dans ton cas, ils servent.
25/02/2022, 14h06
hbx360

Citation:

Envoyé par WhiteCrow

Cette instruction fait un ET bit à bit entre destination et source et stocke le résultat dans destination ⇒ destination = destination AND source.
En gros, le «résultat est stocké dans un registre». Pour «stocker le résultat d'un AND dans un registre» il faut commencer par placer la valeur de nTmp dans ce registre puis de dire avec quelle valeur tu veux faire un AND bit à bit.

Citation:

Envoyé par Sve@r

Dans l'UAL (Unité Arithmétique et Logique). Elle a ses propres zones de travail lui permettant de calculer X operateur Y.

Citation:

Envoyé par Bktero

"où sont mis les résultats des opérations intermédiaire ?" = et bien dans le registre que le compilateur aura choisi d'utiliser (ou sur la pile ou là où le compilateur aura décidé)

C'est cette réponse/confirmation que je recherchais quand j'ai posé ma question.

Citation:

Envoyé par WhiteCrow

Sais-tu ce qu'est un registre ? Comment fonctionne un x86 (en très gros) ? quel est le modèle mémoire de C ? …

Non je ne connais pas.

Citation:

Envoyé par Sve@r

Et puis au bout du compte, est-ce vraiment important ???

Oui pour moi sa compte.

Merci à vous tous pour votre aide et les informations que vous m'avez donné, les explications avec l'assembleur son vraiment intéressante.

Je met en résolu.
26/02/2022, 11h57
Kannagi

Après , il faut se méfier du x86 entre le code écrit et comment il fonctionne en interne , y'a un monde :p

Citation:

Envoyé par WhiteCrow

Maintenant il y a aussi d'autre architecture où cela sera fait autrement … tout simplement parce que d'autres architectures pourraient proposer un opcode qui fait d'un coup ce que ton code source demande (un peu à la BSWAP du x86).

Même si c'est peu probable vu que de nos jours on est plus sur une logique RISC , il faudrait vraiment une analyse sérieuse pour rajouter ce type d'instruction (qui serait de l'utilisé souvent).
En général , on laisse les instruction SIMD et autre spécialisé pour gérer des calculs lourd si besoin.
(Mais 90% du code ,c'est du load/store/add/branchement )
27/02/2022, 16h46
Guesset

Le RISC du CISC ?

Bonjour Kannagi,

Citation:

Envoyé par Kannagi

...Même si c'est peu probable vu que de nos jours on est plus sur une logique RISC , il faudrait vraiment une analyse sérieuse pour rajouter ce type d'instruction (qui serait de l'utilisé souvent).
En général , on laisse les instruction SIMD et autre spécialisé pour gérer des calculs lourd si besoin...

Comme pshufb qui promène les octets et les mets éventuellement à 0 ? Ce qui plombe ce type d'instructions est qu'il faut aussi charger l'argument de ventilation des octets. Si ce n'est pas vraiment intéressant ici, c'est idéal pour, par exemple, changer (très) rapidement l'ordre des composantes couleurs d'une image.

Pour l'instant, les processeurs CISC restent très largement majoritaires sur ordinateur (et absents des smartphones et de la plupart des tablettes). Cela changera peut être si l'initiative d'Apple fait des émules. Mais Apple nous a habitué à changer régulièrement de processeur sans s'occuper réellement de la rétrocompatibilité.

Salut
04/03/2022, 09h25
Kannagi

Citation:

Envoyé par Guesset

Bonjour Kannagi,
Pour l'instant, les processeurs CISC restent très largement majoritaires sur ordinateur (et absents des smartphones et de la plupart des tablettes). Cela changera peut être si l'initiative d'Apple fait des émules. Mais Apple nous a habitué à changer régulièrement de processeur sans s'occuper réellement de la rétrocompatibilité.

*sur PC
Pourquoi pour les processeurs CISC ?
A ma connaissance y'en a qu'un seul c'est le x86 (tout les autres processeurs CISC ont disparu de la circulation).
Et si il est majoritaire (pour le PC) ,c'est plus pour des raisons historique (rétrocompatibilité) que par un avantage quelconque niveau ISA.
04/03/2022, 13h53
Guesset

Bonjour Kannagi,

Citation:

Envoyé par Kannagi

*sur PC

Sur PC et serveurs (non Personal Computer 8-)).

Citation:

Envoyé par Kannagi

Pourquoi pour les processeurs CISC ?

Par complétude avec les RISC par définition.

Citation:

Envoyé par Kannagi

A ma connaissance y'en a qu'un seul c'est le x86 (tout les autres processeurs CISC ont disparu de la circulation). Et si il est majoritaire (pour le PC) ,c'est plus pour des raisons historique (rétrocompatibilité) que par un avantage quelconque niveau ISA.

Il ne faut pas confondre processeurs (i7, Zen5...) et ISA (x86, x64...) et il y a des différences d'ISA entre Intel et AMD (par exemple SSE 4). La concentration industrielle est toujours à l'œuvre. A part ARM, y a t'il d'autres ISA RISC non marginales (y compris ISA open source V) ?

Ceci étant je n'ai pas de chapelle. Je n'ai avancé que des faits. La rétrocompatibilité est effectivement un moteur important et appréciable pour x86 comme ARM. La profusion d'instructions a des avantages mais également des défauts. Notamment, les compilateurs peinent à tirer partie des instructions non élémentaires. Mais réduire les avantages putatifs à l'ISA ne me semble pas légitime car cela ne définit en rien les performances et cela induirait plutôt un avantage CISC (richesse du jeu d'instructions) en masquant le potentiel d'optimisation des jeux d'instruction réduits (implémentation, compilateurs plus efficients, moindre surface silicium etc.)

Salut
04/03/2022, 16h43
Kannagi

Citation:

Envoyé par Guesset

Il ne faut pas confondre processeurs (i7, Zen5...) et ISA (x86, x64...) et il y a des différences d'ISA entre Intel et AMD (par exemple SSE 4). La concentration industrielle est toujours à l'œuvre. A part ARM, y a t'il d'autres ISA RISC non marginales (y compris ISA open source V) ?

Je ne les confonds pas et il n'ya rien sur mon message qui laisse interprétation que je confond les deux , je parlais bien des processeurs avec design CISC.
Il y'a beaucoup de processeur RISC , mais pour le moment seul ARM et RISC-V ont le vent au pourpre (et avant PowerPC et MIPS).
Et le Atmel AVR qui équipe pas mal d'Arduino sont RISC eux aussi.

Citation:

Envoyé par Guesset

Ceci étant je n'ai pas de chapelle. Je n'ai avancé que des faits. La rétrocompatibilité est effectivement un moteur important et appréciable pour x86 comme ARM. La profusion d'instructions a des avantages mais également des défauts. Notamment, les compilateurs peinent à tirer partie des instructions non élémentaires. Mais réduire les avantages putatifs à l'ISA ne me semble pas légitime car cela ne définit en rien les performances et cela induirait plutôt un avantage CISC (richesse du jeu d'instructions) en masquant le potentiel d'optimisation des jeux d'instruction réduits (implémentation, compilateurs plus efficients, moindre surface silicium etc.)

Le soucis de la rétrocompatibilité est :

Citation:

"Adapter de vieux programmes à de nouvelles machines signifie habituellement adapter les nouvelles machines pour qu'elles se comportent comme les anciennes."
Alan Jay Perlis

Sinon un mauvais ISA peut réduire les perfs oui (genre un décodage complexe , ou une mauvaise gestion des branchements ).

Pour les hautes performances, ça y joue moins mais justement le x86 consomme et coûte bien plus chère à produire , c'était mon message d'origine pour cela qu'il n'apporte aucun avantage tangible.
Les instructions CISC vu qu'elle sont convertis en RISC en interne (sur Intel/AMD) , ne gagne que le facteur "place" , mais techniquement la moyenne des opcode du x86 n'est pas plus grande qu'un ARM ou RISC-V.

Fuseau horaire GMT +2. Il est actuellement 04h36.