Discussion :

[Array]

Bonjour,

Voici une citation:

[...]
The assembler takes care of converting the decimal number 158 to its doubleword length 2's complement representation 0000009E. The bytes of this doubleword are actually stored backwards in the object code, a fact that we can almost always ignore.

Pourquoi est-ce que les bytes sont "stored backwards" dans "l'object code"?
Est-ce comme ça que ça se passe dans la mémoire vive du 80x86 en général aussi?
Où seulement dans le code objet?

Cordialement,
Array

[ToutEnMasm]

En clair (et en français), les nombres écrits dans l'assembleur(fichiers textes .asm..) sont écrits dans un format compréhensible par le microprocesseur dans les fichiers objets.
Ce n'est pas uniquement valable pour les nombres décimaux,il y a aussi les réels...

[Forthman]

Ca me rappelle le "fight" entre les 68000 et les 8086.
qui était le plus logique ?
le 68000 codait les octets dans le sens de la lecture :
exemple :
BC12h : adresse n = BCh adesse n+1 = 12h

Alors que l'intel faisait l'inverse (poids faible en premier)
même exemple :
BC12h : adresse n = 12h adresse n+1 = BCh

Personnellement je trouve la méthode Intel assez logique, surement parce que
j'y suis habitué depuis des années

[Prof]

Il y a deux manières possibles de stocker les nombres.

Lectures conseillées :

http://www.ai.univ-paris8.fr/~fb/Cou...big-endian.pdf

http://fr.wikipedia.org/wiki/Endianness

[Obsidian]

Bonjour,

Voici une citation:

[...]
The assembler takes care of converting the decimal number 158 to its doubleword length 2's complement representation 0000009E. The bytes of this doubleword are actually stored backwards in the object code, a fact that we can almost always ignore.

Pourquoi est-ce que les bytes sont "stored backwards" dans "l'object code"?
Est-ce comme ça que ça se passe dans la mémoire vive du 80x86 en général aussi? Où seulement dans le code objet?

C'est un peu fumeux, comme commentaire : je ne vois pas du tout en quoi « 9E » serait le complément à 2 de 158 !

Pour le reste l'endianess est un principe très répandu dans le monde des micro-processeurs. Lorsque qu'une valeur s'étend sur plus d'un mot binaire (comprendre par là : une unité d'adressage, donc généralement « un octet » sur les micro-processeurs les plus courants), ceux qui utilisent le big endian comment par le « bout le plus grand (la gauche du nombre), c'est-à-dire stockent le nombre en mémoire de la manière dont on l'écrit sur papier, et ceux qui utilisent le little endian commencent par la droite, et stockent donc ce nombre à l'envers, mais octet par octet.

Donc, le nombre 12345678h sera stocké en mémoire 78563412h.

Cela est dû à des considérations principalement technologiques. En procédant ainsi, le micro-processeur peut utiliser un système de pile pour faire ses enregistrements et relectures mais également de garder une compatibilité entre les instructions de différents formats. Ainsi, selon les formats, « 9E » sera enregistré comme suit en mémoire :

8 bits : 9E
16 bits : 9E 00
32 bits : 9E 00 00 00
64 bits : 9E 00 00 00 00 00 00 00

De cette façon, chaque format reprend le précédent et l'étend. C'est pratique tant d'un point de vue électronique que logiciel car, dans ce dernier, cas, quel que soit le format, la donnée démarre toujours à la même adresse. Et si on utilisé dès le départ le plus long format, il suffit de lire directement la mémoire à partir du premier octet pour que le « transtypage » soit automatique. Autrement, il aurait fallu tenir compte de la taille de la donnée initiale et calculer un offset en conséquence.

Maintenant, c'est un bien pour un mal : c'est effectivement beaucoup plus pénible pour les programmeurs de bas niveau qui doivent eux-mêmes remettre les données dans l'ordre lorsqu'ils examinent les dump mémoire. C'est chiant aussi lorsque l'on veut remplir une grande zone de mémoire avec des données ordonnées dans le but de l'exporter. Ça oblige à faire la conversion, même si les x86 proposent SWAP qui permet de renverser l'endianess d'un mot en une seul fois.

[Array]

En procédant ainsi, le micro-processeur peut utiliser un système de pile pour faire ses enregistrements et relectures mais également de garder une compatibilité entre les instructions de différents formats.

Est-ce que je pourrais aller plus loin en posant la question: Quel genre de systeème de pile le processeur utilise-t-il? Quand je fais 234h * 345h, comment le processeur fait-il pour faire la multiplication?! Est-ce qu'il inverse lui-même les nombres, effectue la multiplication, et ré-inverse le nombre ensuite?

[Obsidian]

Est-ce que je pourrais aller plus loin en posant la question: Quel genre de systeème de pile le processeur utilise-t-il? Quand je fais 234h * 345h, comment le processeur fait-il pour faire la multiplication?! Est-ce qu'il inverse lui-même les nombres, effectue la multiplication, et ré-inverse le nombre ensuite?

Oui, la gestion de l'endianess est transparente pour le programmeur (tant que l'on reste sur le même format, bien sûr). Tout registre chargé ou sauvegardé par un x86 l'est automatiquement en little endian. La valeur en question est donc déjà dans le bon sens avant d'être traitée et ce, même si tu adresses directement la mémoire sans passer explicitement par un registre. C'est vrai également pour tous les modes d'adressages, y compris le mode immédiat quand la donnée suit immédiatement le code opération.