little endian vs big endian - Page 1

En fait, je me demandait comment fait un x86 (ou tout autre proc en big endian) pour faire les decalage (shifts) ...

Et du coup, meme chose pour les multiplication ...
Et puis pareil pour les additions (retenue) ...

Alors soit, j'ai rien compris, soit je vois pas du tout l'interet du big endian ...

C d'la merde, rien ne vaut le modèle de Motorola.

[Pollux] t'es DIEU!

big endian

[Pollux]> C'est géré en little endian en interne ?
Ouais, du coup, plus de pb pour les operations ...
Bah alors ou est l'interet de l'ecrire en big endian en mem ...

Parceque bon, si ce truc existe, ca doit bien avoir des avantages, non ?
Ou au moins une raison d'exister ?

Lol!
c'est que t'as rien compris,c'est plus rapide

eh dark j'ai des infos sur les tps d'exec dans le forum "une super qst" tu peux y aller?

Raté, vous avez tout faux :

joshua:~$ m /usr/include/bits/endian.h
/* i386 is little-endian. */

#ifndef _ENDIAN_H
# error "Never use <bits/endian.h> directly; include <endian.h> instead."
#endif

#define __BYTE_ORDER __LITTLE_ENDIAN

Ben pour le big endian, il faut aussi renverser les bits a l'interieur des octets :

$0A01 = %0000 1010 0000 0001
sera vu comme :
%1000 0000 0101 0000

Voila.
Les 2 sont logiques et c pour ca que les 2 existent. Mais la logique d'intel est plus sympa lorsque tu veux augmenter la precision. La logique de moto est plus sympa avec l'interface memoire.

notez qu'il n'y a pas que ces 2 là :

/* Definitions for byte order, according to significance of bytes, from low
addresses to high addresses. The value is what you get by putting '4'
in the most significant byte, '3' in the second most significant byte,
'2' in the second least significant byte, and '1' in the least
significant byte. */

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN 4321
#define __PDP_ENDIAN 3412

<<<
Ben pour le big endian, il faut aussi renverser les bits a l'interieur des octets :

$0A01 = %0000 1010 0000 0001
sera vu comme :
%1000 0000 0101 0000
>>>
Nan nan nan. Le big endian, c'est le 68k. Il n'y a pas d'inversion de bits, pas plus que sur le x86.

NON !!!
comme dis JM il n'y a aucune inversion de bits
il y a juste 2 façon de les représenter, et vu que les français font rien comme les autres y en a qui mettent le bit 0 à gauche...
la norme la plu courante est de partir du MSB :

b31 b0
1 0 1 0 0 1 ... 0 0 1 0

l'endianess n'est rien de plus non plus que la façon de stoquer les valeurs en mémoire, mais le cpu fait bien comme il veut après dans les registres ($0A01 sera toujour $0A01)

Oki, mais alors ou est l'interet de l'ecrire "a l'envers" en memoire ?

Euh, je veut dire que $12346578 et ecrit en memoire $78653412 par un x86 et $12345678 par un 68k ...

aucun (à priori), c'est juste un choix, comme le fait que les retour à la ligne sous DOS c'est "rn", "n" sous UNIX et "r" (euh je suis plus sur là...) sous MacOS. C'est juste pour faire chier le monde

Non,non,non. Je certifie, a l'interieur du proc Intel, c fait comme j'ai dit.