long double (GCC spécifique) et float128

Je cherche des informations détaillées sur long double et __float128 dans GCC/x86 (plus par curiosité qu'à cause d'un problème réel).

Peu de gens auront probablement besoin de ceux-ci (j'ai juste, pour la première fois, vraiment besoin d'un double), mais je suppose qu'il vaut toujours la peine (et intéressant) de savoir ce que vous avez dans votre boîte à outils et de quoi il s'agit.

Dans cette optique, veuillez excuser mes questions un peu ouvertes:

1. Quelqu'un pourrait-il expliquer le justification de la mise en œuvre et utilisation prévue de ces types, également en comparaison les uns des autres? Par exemple, sont-ils des "implémentations embarrassantes" parce que la norme autorise le type, et quelqu'un peut se plaindre s'ils ont juste la même précision que double, ou sont-ils destinés à être des types de première classe?
2. alternativement, quelqu'un a-t-il une bonne référence Web utilisable à partager? Une recherche Google sur "long double" site:gcc.gnu.org/onlinedocs ne m'a pas donné beaucoup de choses vraiment utiles.
3. en supposant que le commun mantra "Si vous croyez que vous avez besoin de double, vous ne comprenez probablement pas le point flottant" ne s'applique pas, c'est-à-dire que vous avez vraiment besoin de plus de précision quefloat, et on se fiche de savoir si 8 ou 16 octets de mémoire sont brûlés... est-il raisonnable de s'attendre à ce que l'on puisse aussi bien passer à long double ou __float128 au lieu de double sans impact significatif sur les performances?
4. la fonctionnalité" précision étendue " des processeurs Intel a toujours été source de mauvaises surprises lorsque les valeurs ont été déplacées entre la mémoire et les registres. Si en fait 96 bits sont stockés, le type long double devrait éliminer ce problème. D'un autre côté, je comprends que le type long double est mutuellement exclusif avec -mfpmath=sse, car il n'y a pas de "précision étendue" dans SSE. __float128, d'autre part, devrait fonctionner parfaitement avec SSE math (bien qu'en l'absence d'instructions de précision quad certainement pas sur une base d'instructions 1:1). Suis-je le droit dans ces hypothèses?

(3. et 4. peut probablement être compris avec un peu de travail consacré au profilage et au démontage, mais peut-être que quelqu'un d'autre avait la même pensée auparavant et a déjà fait ce travail.)

Contexte (ceci est la partie TL;DR):
J'ai d'abord trébuché sur long double parce que je regardais DBL_MAX dans <float.h>, et incidentiellement LDBL_MAX est sur la ligne suivante. "Oh regardez, GCC a en fait des doubles de bits 128, pas que j'en ai besoin,mais ... cool " était ma première pensée. Surprise, Surprise: sizeof(long double) retours 12... attends, tu veux dire 16?

Les standards C et c++ sans surprise ne donnent pas une définition très concrète du type. C99 (6.2.5 10) dit que les nombres de double sont un sous-ensemble de long double alors que C++03 unis (3.9.1 8) long double a au moins autant de précision que double (qui est la même chose, seulement libellée différemment). Fondamentalement, les normes laissent tout à la mise en œuvre, de la même manière qu'avec long, int, et short.

Wikipedia dit que GCC utilise "précision étendue sur 80 bits sur les processeurs x86 quel que soit le stockage physique utilisé".

La documentation GCC indique, toutes sur la même page, que la taille du type est de 96 bits à cause de l'ABI i386, mais pas plus de 80 bits de précision sont activés par n'importe quelle option (hein? Comment?), aussi Pentium et les processeurs plus récents veulent qu'ils soient alignés en tant que nombres de bits 128. Ceci est la valeur par défaut sous 64 bits et peut être activé manuellement sous 32 bits, résultant en 32 bits de zéro padding.

Temps D'exécution d'un test:

#include <stdio.h>
#include <cfloat>

int main()
{
#ifdef  USE_FLOAT128
    typedef __float128  long_double_t;
#else
    typedef long double long_double_t;
#endif

long_double_t ld;

int* i = (int*) &ld;
i[0] = i[1] = i[2] = i[3] = 0xdeadbeef;

for(ld = 0.0000000000000001; ld < LDBL_MAX; ld *= 1.0000001)
    printf("%08x-%08x-%08x-%08xr", i[0], i[1], i[2], i[3]);

return 0;
}

La sortie, lors de l'utilisation de long double, ressemble un peu à ceci, les chiffres marqués étant constants, et tous les autres finissent par changer à mesure que les nombres deviennent de plus en plus grands:

5636666b-c03ef3e0-00223fd8-deadbeef
                  ^^       ^^^^^^^^

Cela suggère que c'est pas {[73] } un nombre de 80 bits. Un nombre de 80 bits a 18 chiffres hexadécimaux. Je vois 22 chiffres hexadécimaux changer, ce qui ressemble beaucoup plus à un nombre de 96 bits (24 chiffres hexadécimaux). Ce n'est pas non plus un nombre de 128 bits puisque 0xdeadbeef n'est pas touché, ce qui est cohérent avec sizeof renvoyant 12.

La sortie de __int128 ressemble à un nombre de 128 bits. Tous les bits finissent par basculer.

Compiler avec -m128bit-long-doublene pas aligner long double à 128 bits avec un remplissage zéro de 32 bits, comme indiqué par la documentation. Il n'utilise pas non plus __int128, mais semble en effet s'aligner sur 128 bits, en remplissant avec la valeur 0x7ffdd000 (?!).

En Outre, LDBL_MAX, semble fonctionner comme +inf pour les deux long double et __float128. L'ajout ou la la soustraction d'un nombre comme 1.0E100 ou 1.0E2000 vers / depuis {[18] } entraîne le même motif de bits.
Jusqu'à présent, je croyais que les constantes foo_MAX devaient contenir le plus grand nombre représentable qui n'est pas +inf ( apparemment ce n'est pas le cas?). Je ne sais pas non plus comment un nombre de 80 bits pourrait éventuellement agir comme +inf pour une valeur de 128 bits... peut-être que je suis trop fatigué à la fin de la journée et que j'ai fait quelque chose de mal.