Question bitshift

Si j’ai un byte, il prend ses valeurs entre 0 et 255 inclus.
Si je lui applique un bitshift, il peut arriver que sa valeur dépasse ces bornes :

byte b = 128; // b01000000;
b <<= 3;

devrait me donner 512. De même :

  b = 2; // b00000010;
  b >>= 3;

devrait me donner 1/2.
Comme c’est en dehors des bornes du byte, j’obtiens 0 dans les deux cas.

Mais, que devient le ‘1’ de ma représentation binaire : est-ce qu’il disparait purement et simplement de la mémoire de stockage ou bien est-il décalé dans les cases à côté de celle où est stocké mon octet ?

Il disparaît, pas d'inquiétude.

Ouf, merci !

c’est aussi parce que votre variable est déclarée en byte.

Si c’était un unsigned int (2 octets) ou un unsigned long (4 octets) alors ça toucherait les octets de poids fort lors du décalage à gauche

Il disparaît, pas d'inquiétude.

Quand on fait un décalage en C, c'est traduit par un ou plusieurs décalage/rotation en langage machine les bits qui sortent sont mis dans un drapeau appelé retenue (carry flag). Ceci permet entre autre de décaler des mots de plus grande taille que celle du micro. il ne disparait pas vraiment, il est rangé dans cette retenue. Il sera écrasé par l'opération suivante qui utilise ce bit (décalages, additions, incrémentation...).
Si on fait un décalage de 3 crans avec un AVR, on fait 3 décalages de 1 cran, et à chaque fois, le bit qui sort est écrasé par le décalage suivant. Le dernier reste jusqu'à ce qu'il soit écrasé.
En C, on ne peut pas le récupérer, saut en utilisant de l'assembleur inline.

Si c'était un unsigned int (2 octets) ou un unsigned long (4 octets) alors ça toucherait les octets de poids fort lors du décalage à gauche

Ce n'est pas le décalage de l'octet de poids faible qui va toucher à l'octet de poids supérieur, c'est parce que quand on demande un décalage d'un mot de 2 ou 4 octets avec un micro 8 bits, on décale une fois tous les octets. le premier décalage met le bit qui disparaît dans la retenue, et c'est le deuxième décalage sur l'octet de poids 256 qui reprend ce bit (1 ou 0).
Avec un AVR si on décale un 32 bits de 24 positions vers la gauche, il n'y a plus vraiment de décalages avec l’optimisation par défaut. On met simplement l'octet de poids le plus faible, on le met dans l'octet de poids le plus fort, puis on met à 0 les trois octets de poids faible. Pareil si on veut décaler de 16 positions vers la gauche. Je suppose qu'il en est ainsi vers la droite aussi.

Ce n’est pas le décalage de l’octet de poids faible qui va toucher à l’octet de poids supérieur, c’est parce que quand on demande un décalage d’un mot de 2 ou 4 octets avec un micro 8 bits, on décale une fois tous les octets. le premier décalage met le bit qui disparaît dans la retenue, et c’est le deuxième décalage sur l’octet de poids 256 qui reprend ce bit (1 ou 0).

Oui vous avez raison. Je décrivais le résultat visible du point de vue du programmeur - pas la mécanique interne.

vileroi:
Si on fait un décalage de 3 crans avec un AVR, on fait 3 décalages de 1 cran (...)

à partir d'un certain nombre de décalages vers la gauche (4 je crois), le compilateur préfère utiliser le multiplicateur

à partir d'un certain nombre de décalages vers la gauche (4 je crois), le compilateur préfère utiliser le multiplicateur

En tout ca pas pour les long, j'ai vu que même pour 30 décalage, il ne fait pas la multiplication. Voir post sur la multiplication par 1024