C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé
C'est possible, mais ça ne change pas le fait que tu n'as aucun moyen de le savoir au niveau de la programmation.
Quand tu te retrouves sur une machine Little Endian (PC x86 dans mon cas), tu peux voir que l'ordre des octets est inversé en mémoire, quand tu stockes une valeur sur plus d'un octet (un entier 32 bits en particulier), par exemple en faisant "od -x fichier.bin" tu peux voir que les octets sont inversés 2 par 2 car les données sont lues par défaut sur 2 octets; pour avoir un affichage normal, il faut faire "od -t x1 fichier.bin" (casse-pieds quand on vient du monde 680x0 Big Endian). Les bits d'un octets apparaissent dans l'ordre normal (heureusement, sinon la machine serait difficilement utilisable !).
D'où ma surprise avec ton explication où tu inverses les bits au sein d'un octet; ça embrouille pour rien.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 2.
C'est possible, mais ça ne change pas le fait que tu n'as aucun moyen de le savoir au niveau de la programmation.
Quand tu te retrouves sur une machine Little Endian (PC x86 dans mon cas), tu peux voir que l'ordre des octets est inversé en mémoire, quand tu stockes une valeur sur plus d'un octet (un entier 32 bits en particulier), par exemple en faisant "od -x fichier.bin" tu peux voir que les octets sont inversés 2 par 2 car les données sont lues par défaut sur 2 octets; pour avoir un affichage normal, il faut faire "od -t x1 fichier.bin" (casse-pieds quand on vient du monde 680x0 Big Endian). Les bits d'un octets apparaissent dans l'ordre normal (heureusement, sinon la machine serait difficilement utilisable !).
D'où ma surprise avec ton explication où tu inverses les bits au sein d'un octet; ça embrouille pour rien.