Obtenir le tableau de bits d'un entier

ceburo

Bonjour,

Voilà , j'aimerais stocker dans un "Byte tab[8]" les bits représentant un entier de 0 à  255.

J'ai regardé du côté des parsers mais j'ai rien trouvé.

Sauf en calculant moi-même chaque bit, mais c'est dommage si une méthode existe déjà .

Merci.

Céroce

C'est du langage C standard:

typedef struct ChampDe8Bits_s<br />{<br />unsigned char bit0 : 1;<br />unsigned char bit1 : 1;<br />unsigned char bit2 : 1;<br />unsigned char bit3 : 1;<br />unsigned char bit4 : 1;<br />unsigned char bit5 : 1;<br />unsigned char bit6 : 1;<br />unsigned char bit7 : 1;<br /><br />} ChampDe8Bits;

Par contre: l'ordre des bits (bit de poids faible déclaré en premier) doit être bon sur PowerPC, mais je ne sais pas pour les processeurs ARM. Il faut donc que tu vérifies.

Philippe49

C'est quand même curieux qu'il n'ait pas été prévu un format %binaire.
On a sprintf(aString,"%o",aNumber); sprintf(aString,"%x",aNumber);
et sprintf(aString,"%d",aNumber); pour écrire en octal, en hexa et en décimal et rien à  ma connaissance en binaire.
Dans l'autre sens par contre, on a strtol qui permet de choisir la base.

#define bytesString(a) (char [9]){(((a)&amp;128)&gt;&gt;7)+&#39;0&#39;,(((a)&amp;64)&gt;&gt;6)+&#39;0&#39;,(((a)&amp;32)&gt;&gt;5)+&#39;0&#39;,(((a)&amp;16)&gt;&gt;4)+&#39;0&#39;,(((a)&amp;8)&gt;&gt;3)+&#39;0&#39;,(((a)&amp;4)&gt;&gt;2)+&#39;0&#39;,(((a)&amp;2)&gt;&gt;1)+&#39;0&#39;,((a)&amp;1)+&#39;0&#39;,0}<br /><br />int main(void) {<br />	int a;<br />	for(a=0;a&lt;256;a++)<br />		printf(&quot;%s&#092;n&quot;, bytesString(a));		<br />	return 0;<br />}

Céroce

Effectivement, en C on ne peut pas faire une simple affectation en binaire, mais je crois que c'est un choix qui a été fait pour des raisons de lisibilité. Au-delà  de 8 bits, les chiffres binaires représentent trop de risque de se tromper, alors que la conversion hexa<->binaire est relativement aisée à  faire de tête.

Philippe49

Ecriture inverse : chaà®ne --> long
(atoi, atof sont notés deprecated depuis quelques années maintenant)

<br />int main(void) {<br />	long a,n;<br />	char s[9]=&quot;101011&quot;;<br />	a=strtol(s,NULL,2);		<br />	printf(&quot;%X&#092;n&quot;, a);<br />	return 0;<br />}

résultat 2B

zoc

dans 1243856384:

Par contre: l'ordre des bits (bit de poids faible déclaré en premier) doit être bon sur PowerPC, mais je ne sais pas pour les processeurs ARM. Il faut donc que tu vérifies.

L'ordre des bits dans un octet est toujours le même quelle que soit l'architecture. C'est l'ordre des octets dans un mot comportant plus d'un octet qui varie en fonction de "l'endianisme"...

Céroce

dans 1243866075:

L'ordre des bits dans un octet est toujours le même quelle que soit l'architecture. C'est l'ordre des octets dans un mot comportant plus d'un octet qui varie en fonction de "l'endianisme"...

Oui, mais ce n'est pas la question. La question est de savoir si le premier champ de bit correspond au bit de poids fort ou de poids faible. D'après le Kernighan et Ritchie, "ça dépend de l'implémentation" (comme toujours pour tout ce qui concerne les manipulations de bits). Mais effectivement, ça dépend plutôt du compilateur et des options de compilation que de la cible.

Mala

dans 1243869909:

dans 1243866075:

L'ordre des bits dans un octet est toujours le même quelle que soit l'architecture. C'est l'ordre des octets dans un mot comportant plus d'un octet qui varie en fonction de "l'endianisme"...

Oui, mais ce n'est pas la question.

Heu bien si. Puisqu'il n'est question que d'un seul octet la question ne se pose pas ici. Zoc a raison.

zoc

Ce que veut dire Céroce, et il a raison, c'est que quand on écrit une structure "champ de bits" comme celle qu'il a écrite, on ne sait pas dans quel ordre le compilateur va "placer" chaque bit dans l'octet, car ce n'est pas normalisé et donc chaque compilateur implémente un champ de bits comme il veut.

La seule solution portable pour l'extraction d'un bit à  une position donnée dans un octet, c'est par masquage et décalage (Enfin, quand on veut tester un seul bit à  la fois, un simple masquage et une comparaison avec 0 suffisent).

ceburo

Ha ben je m'absente toute la journée, et voilà  que j'ai tout plein de réponses. Merci tout le monde.

Pour le moment, j'ai pas regardé la méthode de codage de l'ARM, je voulais juste savoir si il existait une méthode dans le sdk permettant de passer de 26 à  00011010 par exemple.

A ce que j'ai lu, je vais devoir implémenter ma propre petite fonction de calcul ? Tant pis, ça prend un peu de place dans le code, c'est dommage si Apple n'y a pas pensé.

Céroce

dans 1243884982:

La seule solution portable pour l'extraction d'un bit à  une position donnée dans un octet, c'est par masquage et décalage (Enfin, quand on veut tester un seul bit à  la fois, un simple masquage et une comparaison avec 0 suffisent).

Et encore, même le décalage n'est pas normalisé. En pratique, il s'agit presque toujours d'un décalage logique, les rares cas où c'est un décalage arithmétique (c.à .d. qui conserve le bit de signe), c'est lorsque le microprocesseur n'a pas d'instruction de décalage logique (ça existe, mais c'est devenu très rare).

Maintenant, j'ai essayé de chercher un peu dans la doc de gcc (c'est bien lui qui compile pour l'iPhone ?), et en gros, ils s'attachent à  ce que le code produise le même résultat quelque soit l'architecture. De fait, la structure que j'ai proposé devrait fonctionner sur tous les microprocesseurs de la même façon.

Céroce

dans 1243886943:

Pour le moment, j'ai pas regardé la méthode de codage de l'ARM, je voulais juste savoir si il existait une méthode dans le sdk permettant de passer de 26 à  00011010 par exemple.

Nous l'avons déjà  expliqué ici, mais voici un résumé:
- tous les nombres sont forcément stockés en binaire en mémoire
- le décimal, héxadécimal, octal, etc. ne sont que des représentations. Les méthodes sprintf() et compagnie convertissent les données binaires en chaà®nes de caractères.
- sprintf() et compagnie ne savent pas afficher une représentation en binaire -> affiche-les en héxadécimal, ou utilise le code fourni par Philippe.