Reprise du message précédent :
ah ... bien ... c koi le boutisme ?

 
C'est dans les voyages de Gullivert...
 
faut il manger les oeufs à la coque par le gros bout, ou le petit bout de l'oeuf ?

C'est l'art de savoir parler à la fois au grands et aux petits indiens

?!???????

une histoire d'endianess

Il s'agit de l'ordre dans lequel sont placés en mémoire les morceaux dont est fait un tout.
On commence par ceux qui ont le...
grand boutiste/big    endian : ...plus ...
petit boutiste/little endian : ...moins...
...de poids pour la valeur du tout.
 
 
Pour un int 0x11223344 écrit à l'adresse 0000, les octets sont placés comme suit:

 
Pour les bits:

u.i vaudra...
Intel (little endian): ...1.
Motorola (big endian): ...la plus basse valeur négative possible.
 
 
Et puis il y a déjà des posts qui en parlent...

J'avais lu dans une doc de Sun qu'il existait aussi du middle endian
 
0x11223344 serait alors socke comme

le little endian est logique pour un proc 8 bits
on commence toujours les additions par les les unitées...
 
le ME serait logique pour un proc 16 bits
 
le BE serait logique pour un proc 32 bits....

heureusement que la on parle de nbres sur 4 octets, sinon sur 8 ou 16 vu kil y a d'autres possibilités pour les coder, j'ose aps imaginer ce qui a encore été inventé ...

 
En fait il faut revenir a l'arthmetique de primaire :
 
pour faire des additions de nombres a plusieurs chiffres tu commence par les unitées, puis tu rapportes l'eventuelle retenue pour faire la somme des chiffres des dizaines et ainsi de suite...
 
 
donc sur un proc quand tu doit faire l'addition de nombre plus gros qu'un mot processeur, tu as interet a ce que les mots soit stockées dans l'ordre des moins significatifs vers les plus significatifs....
 
D'un autre coté quand un mot est plus gros qu'un octet tu as interet a ce que les octets soient dans l'ordre du mot donc a priori les plus significatif en debut...
 
 
Les proc intel s'inscrivent dans la compatibilité du 8086 qui lui-meme etait plus ou moins compatible avec le... ...8080
 
d'ou des mots de 8 bits...

ok ... chez Intel c donc une perte de performance de les stocker dans ce sens la ? (pour garder la compatibilité)

 
C'est plus une complication...
 
de meme que sur intel (8086) tu peut lire a toutes les adresses memoires, alors que sur un 68000 tu ne peux lire qu'aux adresses paires...
 
je ne sais pas si ca genere reelement une perte de perf...
 

Pourquoi ?
Je n'y vois aucun intérêt. La copie est indifférente au boutisme, et se fait souvent par mot.
Puisque l'addition commence par le faible, autant choisir ce bout comme point de départ pour la disposition en mémoire. Ça a l'avantage que les octets/bits ont le même poids quelle que soit la taille de l'entier stocké.
 
Je n'ai jamais compris l'intérêt du big endian.
 
Quand au middle endian, ç'est un croisement monstrueux !
Pourquoi pas du random order ?

ah ! oui ca serait drole du random aussi ))

Le vrai probleme c'est peut etre la maniere dont tu regarde les choses... le middle endian te parrait monstrueux, mais si au lieu de découper la memoire en octets tu la decoupe en mots, ce ni plus ni moins que du little endian...
 

Il est monstrueux d'utiliser un boutisme différent selon la taille du découpage.
Imagine des mots lus de gauche à droite, dans un texte lu de droite à gauche, dans un livre qui se feuillette de gauche à droite...
 
Résultat des courses: pour prendre les octets dans l'ordre, une simple crémentation de pointeur ne suffit pas.
Ce genre d'architecture à cas particuliers est inefficace.
 
 
Le little endian a un autre avantage: si, là où l'on stockait un entier on décide d'en mettre un plus grand, du code ancien reconnaît toujours la valeur si elle tiens dans l'ancien type, car elle occupe le même emplacement.
 
 
Le seul avantage que je vois pour le big endian, c'est qu'il a l'air d'être en ordre quand on le lit dans un éditeur hexadécimal classique qui affiche les octets de gauche à droite. Cruelle illusion.
 
 
D'ailleurs, pendant que j'y suis, ces éditeurs sont monstrueux parce qu'il sont middle-endians: les 2 chiffres hexadécimaux composant les octets sont affichés de droite à gauche comme il sied à un nombre, tandis que les octets sont affichés de gauche à droite comme du texte.
 
Un bon éditeur hexa doit permettre de choisir ces deux sens, mais je n'en ai jamais vu le permettant.

En fait la question ne se pose pas, les sytemes middle endian ne peuvent normalement pas acceder a un octet mais seulement a un mot (c'est le cas du 68000 par exemple)...

bin fait un editeur hexa qui inverse les valeurs si tu veux Musaran