big/little endian

David ROMAN wrote on 21/10/04 :

Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binaire en little ou big endian indifferement ???

Peut être, mais ça n'a aucun intérêt. Ce problème est reglé par le
choix de la cible qui se fait par compilation conditionelle.

Voir

http://mapage.noos.fr/emdel/clib.htm
module HTON

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Jean-Marc Bourguet wrote on 21/10/04 :

Toute valeur peut etre relue comme un tableau d'unsigned char.

Oui, à condition de soir ce qu'il y a dans les char.

Donc

void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}

est valide.

Oui, mais pas portable. L'ordre des char peut précisément changer selon
l'endianness.

Ce qu'il faut faire, c'est utiliser un encodage qui dépend de la cible,
et qui fournit un format commun (par exemple de type réseau, le 'n' de
hton : MSB en tête).

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye wrote:

Jean-Marc Bourguet wrote on 21/10/04 :

Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Oui, mais pas portable. L'ordre des char peut précisément changer selon

l'endianness.

Oui mais à ce que j'ai compris du post de Jean-Marc Bourguet c'est
_justement_ pour tester l'endianness qu'il fait ce code.

Relire la valeur sous forme d'un tableau d'unsigned permet de voir dans quel
sens les bytes ont été stockés et donc d'en déduire l'endianness vu que
lorsque l'on fait ca on connait la valeur de départ.

Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra

James Kanze <james.kanze@free.fr> writes:

Yves ROMAN <yves.roman@NO.unilog.SPAM.fr> writes:

|> int isIntel(void)
|> {
|> long l = 1 ;
|> return *((char *)(&l)) ;
|> }

Je suis un peu curieux en ce qui concerne le nom. Après
tout, la fonction renvoie la même chose, que ce soit un
processeur Intel ou un VAX.

Ca m'a fait me sentir vieux de voir attriber à Intel plutôt
qu'a DEC cet ordre :-)

Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...

Le poids faible d'abord c'est bien le big endian (le gros à la fin ?) ?
Ou j'ai encore tout faux ?

David ROMAN wrote:

Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???

Merci
David

Je dois mal m'exprimer ... excusez moi ....


Bon je vais essayer de me clarifier

l'ordre des bits dans un octet ne changent pas selon les differents
processeurs (est ce qu'on est ok la dessus ?)
Par contre l'ordre des octets dans un mot ou un dble mot ou un dble dble
mot changent c a d

=> pour un court soit un int sur 2 octets octect_1,octect_2 devient
octect_2,octect_1
pour un long octect_1,octect_2,octect_3,octect_4 devient
octect_4,octect_3,octect_2,octect_1
et pour un long long
octect_1,octect_2,octect_3,octect_4,octect_5,octect_6,octect_7,octect_8
devient
octect_4,octect_3,octect_2,octect_1,octect_8,octect_7,octect_6,octect_5


Est ce que je raconte des anneries ou ai je bien tout compris jusqu'a
present ????

Avant d'aller + loin autant etre sur de parler de la meme chose ...

david

David ROMAN <roman@cesr.fr> a écrit:

David ROMAN wrote:

Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???

Merci
David

Je dois mal m'exprimer ... excusez moi ....


Bon je vais essayer de me clarifier

l'ordre des bits dans un octet ne changent pas selon les differents
processeurs (est ce qu'on est ok la dessus ?)
Pas tout à fait, mais ça ne concerne pas la programmation ordinaire en

C. Checher dans Google avec:
endian consistent inconsistent

Par contre l'ordre des octets dans un mot ou un dble mot ou un dble dble
mot changent c a d

=> pour un court soit un int sur 2 octets octect_1,octect_2 devient
octect_2,octect_1
pour un long octect_1,octect_2,octect_3,octect_4 devient
octect_4,octect_3,octect_2,octect_1
et pour un long long
octect_1,octect_2,octect_3,octect_4,octect_5,octect_6,octect_7,octect_8
devient
octect_4,octect_3,octect_2,octect_1,octect_8,octect_7,octect_6,octect_5


Est ce que je raconte des anneries ou ai je bien tout compris jusqu'a
present ????
<hors C>

Au départ, il faut définir l'atome de mémoire, c'est à dire la plus
petite quantité adressable, correspondant à une unité d'adresse. En
x86, c'est l'octet.
Ensuite, il faut voir pour chaque taille plus grande de donnée gérée
par le processeur dans quel ordre celui-ci va les écrire en mémoire.
Soit le WORD (16 bits) 0x1234 à écrire (ou lire) à l'adresse A. Il
occupera A et A+1. Mais il peut écrire soit les poids faibles (0x34)
en A et les poids forts (0x12) en A+1 (little endian), soit l'inverse
(big endian). Si on représente la mémoire adresses croissantes de la
gauche vers la droite, ça donne:
little endian: 34 12
big endian: 12 34
De même pour le DWORD 0x12345678, écrit comme un DWORD:
little endian: 78 56 34 12
big endian: 12 34 56 78
Donc, en dehors des cas d'échanges entre machines, l'endianité nous
intéressera (et éventuellement posera problème) quand la lecture et
l'écriture dans une même zone mémoire se fera au travers de données de
tailles différentes (en C, par transtypage de pointeur). En little
endian, après avoir écrit le DWORD 0x12345678 en A, nous lirons les
BYTE 0x78, 0x56, 0x34, 0x12 dans cet ordre aux adresses A, A+1, A+2 et
A+4. Et les WORD 0x5678, 0x1234 aux adresses A et A+2.
Dernière remarque: il est courant d'entendre que "little endian",
c'est "à l'envers". Ce n'est pas plus vrai que le contraire. Un
avantage de little endian: nous avons à l'adresse A un DWORD dont la
valeur est <= 255, par exemple 69, c'est à dire 0x00000045. Nous
trouvons à l'adresse A également un WORD et un BYTE de même valeur. Vu
comme ça, little endian est "plus logique" que big endian.
</hors C>

Question aux spécialistes du C: est-il possible de concevoir une
machine dont l'atome mémoire (donc la base de l'endianité) serait de
16 bits et la taille du char de 8 bits ?
--
Pierre

Yves ROMAN wrote on 22/10/04 :

Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...

Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

David ROMAN wrote on 22/10/04 :

l'ordre des bits dans un octet ne changent pas selon les differents
processeurs (est ce qu'on est ok la dessus ?)

Ok. (Encore que les processeurs PowerPC (Freescale, ex-Motorola) ont
une drôle de façon de numéroter leurs bits en mode IBM, qui est le mode
par défaut et celui des docs...)

Par contre l'ordre des octets dans un mot ou un dble mot ou un dble dble
mot changent c a d

Oui, mais pas uniquement selon le schéma connu Intel vs (ex-)Motorola.
Il paut y avoir d'autres formats avec les objets >= 4 bytes. Et je ne
parle pas des flottants!

=> pour un court soit un int sur 2 octets octect_1,octect_2 devient
octect_2,octect_1
pour un long octect_1,octect_2,octect_3,octect_4 devient
octect_4,octect_3,octect_2,octect_1
et pour un long long
octect_1,octect_2,octect_3,octect_4,octect_5,octect_6,octect_7,octect_8
devient
octect_4,octect_3,octect_2,octect_1,octect_8,octect_7,octect_6,octect_5


Est ce que je raconte des anneries ou ai je bien tout compris jusqu'a
present ????

Oui, mais ce sont des cas parmi d'autres...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Pierre Maurette wrote on 22/10/04 :

Question aux spécialistes du C: est-il possible de concevoir une
machine dont l'atome mémoire (donc la base de l'endianité) serait de
16 bits et la taille du char de 8 bits ?

Si tu parles d'une machine virtuelle pour exécuter du C, non. Si
l'atome (byte) fait 16 bits, le char fait 16-bits (les 8 bits de poids
forts sont en quelque sorte non utilisés). C'est le cas de certains DSP
Texas.

/********************************************************************/
/* LIMITS.H v3.10 */
/* Copyright (c) 1993-1998 Texas Instruments Incorporated */
/********************************************************************/
#ifndef _LIMITS
#define _LIMITS

#define CHAR_BIT 16 /* NUMBER OF BITS IN TYPE CHAR
*/

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye <emdel@YOURBRAnoos.fr> a écrit:

Yves ROMAN wrote on 22/10/04 :

Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...

Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!
Intel / Little, il me semble que les lettres en commun sont

suffisantes.
Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little
end first, c.à.d. que les poids faibles sont écrits en premier. Mais
bien sûr, pourquoi first et pas last? En fait, j'ai lu que le
mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce
"In" m'échappe.
Personnellement, je mémorise qu'en x86, quand un u32 à une valeur < max d'un u8, on accède à la même adresse à un u32, un u16 et un u8 de
même valeur. Sam Sufy en cas de doute.
--
Pierre