« Fonctionnement d'un ordinateur/Le modèle mémoire : alignement et boutisme » : différence entre les versions

Contenu supprimé Contenu ajouté
Ligne 32 :
Le choix entre petit boutisme et gros boutisme est généralement une simple affaire de convention, tant les différences pratiques entre les deux sont faibles. Il n'y a pas d'avantage vraiment probant pour l'une ou l'autre de ces deux méthodes. Cela ne veut pas dire que n'y a pas d'avantage ou d'inconvénient d'une méthode sur l'autre, mais que ceux-ci sont mineurs. Dans les faits, il y a autant d'architectures petit- que de gros-boutistes, la plupart des architectures récentes étant bi-boutistes. Précisons que le jeu d'instruction x86 est de type petit-boutiste. Si on quitte le domaine des jeu d'instruction, il faut savoir que les protocoles réseaux et les formats de fichiers imposent un boutisme particulier. Les protocoles réseaux actuels (TCP-IP) sont de type gros-boutiste, ce qui impose de convertir les données réseaux avant de les utiliser sur les PC modernes. Et au passage, si le gros-boutisme est utilisé dans les protocoles réseau, alors que le petit-boutisme est roi sur le x86, c'est pour des raisons pratiques, que nous allons aborder ci-dessous.
 
Le gros-boutisme est très facile à lire pour les humains. Les nombres en gros-boutistes se lisent de droite à gauche, comme il est d'usage dans les langues indo-européennes, alors que les nombres en petit boutistes se lisent en lisant les octets dans l'ordre inverse de lecture. Il va de soit que la lecture des nombres en petit-boutiste est bien plus compliquée : non seulement il faut inverser l'ordre des octets, mais il faut garder l'ordre des chiffres dans chaque octet. Par exemple, le nombre 0x015665 (87 653 en décimal) se lit 0x015665 en gros-boutiste, mais 6556010x655601 en petit-boutiste. Et je ne vous raconte pas ce que cela donne avec un ''byte-swap''... Cette différence pose problème quand on doit lire des fichiers, du code machine ou des paquets réseau. Alors certes, il est rare de devoir lire des nombres directement depuis du code machine avec un éditeur hexadécimal. La plupart des professionnels lisent directement les données en passant par des outils d'analyse qui se chargent d'afficher les nombres en gros-boutiste, voire en décimal. Un professionnel a à sa disposition du désassembleur pour le code machine, des analyseurs de paquets pour les paquets réseau, des décodeurs de fichiers pour les fichiers, des analyseurs de ''dump'' mémoire pour l'analyse de la mémoire, etc. Cependant, le gros-boutisme reste un avantage quand on utilise un éditeur hexadécimal, que ce soit pour l'analyse d'un exécutable/fichier/paquet corrompu, ou pour tout autre usage. En conséquence, le gros-boutiste a été historiquement pas mal utilisé dans les protocoles réseaux et les formats de fichiers. Par contre, cet avantage de lecture a dû faire face à divers désavantages pour les architectures de processeur.
 
Pour ce qui est des processeurs, le petit-boutisme peut avoir des avantages dans certaines conditions bien précises, sur certains jeux d'instruction particuliers. En premier lieu, il est utile pour les architectures qui peuvent lire des mots de différentes tailles. C'est le cas sur le x86, où l'on peut décider de lire des mots de 8, 16, 32, voire 64 bits à partir d'une adresse mémoire. Avec le petit-boutisme, on s'assure qu'une telle lecture charge bien la même valeur, le même nombre. Par exemple, imaginons que je stocke le nombre 0x 14 25 36 48 sur un mot mémoire, en petit-boutiste. En petit-boutiste, une opération de lecture reverra soit les 8 bits de poids faible (0x 48), soit les 16 bits de poids faible (0x 36 48), soit le nombre complet. Ce ne serait pas le cas en gros-boutiste, où les lectures reverraient respectivement 0x 14, 0x 14 25 et 0x 14 25 36 48. Avec le gros-boutisme, de telles opérations de lecture n'ont pas vraiment de sens. A la rigueur, elles peuvent servir à obtenir une approximation d'un grand nombre entier, mais cela sert peu et peu se faire autrement avec des opérations bit-à-bit. En soit, cet avantage est assez limité et n'est utile que pour les compilateurs et les programmeurs en assembleur.
 
Un autre avantage est un gain de performance pour certaines opérations bien précises sur certaines processeurs bien précis. Les instructions qui gagnent en performance sont les opérations où on doit additionner un nombre de plusieurs octets sur un processeur qui ne fait les calculs qu'octet par octet. En clair, le processeur dispose d'instruction de calcul qui additionnent des nombres de 16, 32 ou 64 bit, voire plus. Mais à l'intérieur du processeur, les calculs sont faits octets par octets, l'unité de calcul ne pouvant qu'additionner deux nombres de 8 bits à la fois. Dans ce cas, le petit-boutisme garantit que l'addition des octets se fait dans le bon ordre, en commençant par les octets de poids faible pour progresser vers les octets de poids fort. La gestion de la propagation de la retenue est alors assez simple : il suffit de mémoriser la retenue de l'addition précédente dans un registre, avant de passer à l'addition d'octets suivante. En gros-boutisme, la propagation de la retenue pose de plus gros problèmes...
 
Pour résumer, les avantages et inconvénients de chaque boutisme sont mineurs. Le gain en performance est nul sur les architectures modernes, qui ont des unités de calcul capables de faire des additions multi-octets. L'usage d'opérations de lecture de taille variable est aujourd'hui tombé en désuétude, vu que cela ne sert pas à grand chose et complexifie le jeu d'instruction pour presque rien. Enfin, l'avantage de lecture n'est utile que dans situations tellement rares qu'on peut légitimement questionner son statut d'avantage. En bref, les différentes formes de boutisme se valent.
 
==Alignement mémoire==