Discussion :

[baragouine]

Est-ce que quelques soit l'architecture de la machine hôte le format des floats et des doubles suivent ieee-754 (bit de signe, exposant, mantisse le tout en big endian)?

[Astraya]

Non, mais 99% du marché oui. A quelques variantes prêts ( pas de NaN ou INF par exemple) et des architecture exotique comme IBM ou le MIPS de la PlayStation 2....

[baragouine]

Merci

[dalfab]

Bonjour,

A part sur des processeurs pour l'embarqué où on peut avoir des formats particuliers (p.e des doubles sur 4 octets), j'ai toujours vu un format IEEE-754 mais pas toujours en big-endian. Le but est souvent d'avoir le bit de signe à la même position que les entiers et donc des float/double en little-endian.

[baragouine]

Bonjour,

A part sur des processeurs pour l'embarqué où on peut avoir des formats particuliers (p.e des doubles sur 4 octets), j'ai toujours vu un format IEEE-754 mais pas toujours en big-endian. Le but est souvent d'avoir le bit de signe à la même position que les entiers et donc des float/double en little-endian.

Si je comprends bien dans la norme IEEE-754 la mantisse n'est pas forcément en big endian?

[dalfab]

Le séquence est toujours : signe + exposant biaisé + mantisse
Donc le bit de poids faible du double est le bit de poids faible de la mantisse. Ce bit est dans le premier octet en little-endian et dans le dernier en big-endian. C'est normalement transparent à l'utilisateur. Ce code marche toujours (du moins en C, en C++ c'est à éviter):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
union {
    double    db;
    int64_t   in;
    unsigned char tab[8];
};
db = 3.1416;
uint64_t mantisse = in & 0x001FFFFFFFFFFFFFL; // marche toujours, ne dépend pas de l'endianess
assert( (in < 0) == (db < 0) );         // marche toujours (sauf nombre spéciaux : NaN ou -0)
assert( tab[0] == (mantisse & 0xFF) );  // vrai seulement en little-endian
assert( tab[7] == (mantisse & 0xFF) );  // vrai seulement en big-endian

Tant qu'on ne s'intéresse pas au détail des octets, et on a aucune raison de le faire, l'endianess est invisible du code.

[kaitlyn]

Salut,

Est-ce que quelques soit l'architecture de la machine hôte le format des floats et des doubles suivent ieee-754 (bit de signe, exposant, mantisse le tout en big endian)?

Non, il n'y a aucune obligation de ce côté là. La représentation des flottants, boutisme compris, est définie par l'implémentation. Et ça va même plus loin, le compilateur peut utiliser une implémentation complètement différente de celle qui sera utilisée à l'exécution, jusqu'à même produire des résultats très différents pour une même opération, suivant que celle-ci est calculée pendant la compilation ou à l'exécution. Quoiqu'il en soit, C et C++ exposent un certain nombre de macros, constantes ou fonctions qui permettent de savoir si iec(60)559 (nom du standard correspondant à la norme ieee754) est pris en charge, dans quelle mesure et le cas échéant d'affiner sont comportement.

[baragouine]

Ça me donne envie de pleurer, c'est si dur de se mettre d'accord?

[dalfab]

Ça me donne envie de pleurer, c'est si dur de se mettre d'accord?

Ce que l'on dit c'est que ça n'est pas garanti, comme l'a précisé kaitlin tu as des macros pour vérifier si c'est le cas. C'est souvent le cas mais pas toujours, le format effectif est lié au format des données du coprocesseur flottant, le langage n'y est pour rien. C'est pour cela que la norme ne peut pas imposer un format.
La constante std::numeric_limits<double>::is_iec559 indique si le double est bien "ISO/IEC/IEEE 60559:2011 is the same as IEEE 754-2008."

[kaitlyn]

Aussi il n'y a pas toujours de coprocesseur flottant. Et combien même il existerait, rien oblige l'implémentation à l'utiliser. Et même si elle est en mesure de le faire, avec les options adéquates on peut lui demander de ne pas le faire.

Les standards C et C++ définissent ceux que sont les flottants et ce qu'il faut en attendre, pas comment (obligatoirement) y parvenir. Donc quelque part ce degré de liberté est un axe d'innovation. Et c'est d'autant plus remarquable si on regarde du côté de la lib standard, car c'est ce même degré de liberté qui permet à la lib standard d'exister sous forme de différentes implémentations et d'aboutir donc à l'écosystème riche que l'on connaît.