длинный двойной (специфический GCC) и float128

я ищу подробную информацию о long double и __float128 в GCC / x86 (больше из любопытства, чем из-за реальной проблемы).

немногие люди, вероятно, когда-нибудь понадобится (я только, в первый раз в жизни,истинно нужен double), но я думаю, что все еще стоит (и интересно) знать, что у вас есть в вашем наборе инструментов и о чем это.

в этом свете, пожалуйста, извините меня несколько открытым вопросы:

1. может ли кто-нибудь объяснить обоснование реализации и предполагаемое использование этих типов, также в сравнении друг с другом? Например, являются ли они "реализациями смущения", потому что стандарт допускает тип, и кто-то может пожаловаться, если они только с той же точностью, что и double, или они предназначены в качестве первого класса?
2. кроме того, у кого-то есть хорошая, полезная веб-ссылка для обмена? Поиск в Google на "long double" site:gcc.gnu.org/onlinedocs не дал мне много полезного.
3. предполагая, что общая мантра "если вы считаете, что вам нужен double, вы, вероятно, не понимаете плавающую точку" не применяется, т. е. вы действительно нужно больше точности, чем просто float, и вам все равно, будут ли сожжены 8 или 16 байтов памяти... разумно ли ожидать, что можно просто перейти к long double или __float128 вместо double без значительного представления удар?
4. функция "расширенной точности" процессоров Intel исторически была источником неприятных сюрпризов, когда значения перемещались между памятью и регистрами. Если на самом деле хранятся 96 бит, то long double type должен устранить эту проблему. С другой стороны, я понимаю, что long double тип является взаимоисключающим с -mfpmath=sse, поскольку в SSE нет такой вещи, как "расширенная точность". __float128, С другой стороны, должен отлично работать с SSE math (хотя и в отсутствии из четырех точных инструкций, конечно, не на базе инструкций 1:1). Прав ли я в своих предположениях?

(3. и 4. возможно, это можно выяснить с помощью некоторых работ, потраченных на профилирование и разборку, но, может быть, кто-то другой имел ту же мысль ранее и уже сделал эту работу.)

фон (это часть TL; DR):
Я сначала споткнулся long double потому что я смотрел DBL_MAX на <float.h>, и incidentially LDBL_MAX на следующей строке. "О, смотрите, GCC на самом деле имеет 128-битные двойники, не то, чтобы они мне нужны, но... круто" была моя первая мысль. Сюрприз, сюрприз: sizeof(long double) возвращает 12... подожди, ты имеешь в виду 16?

стандарты C и c++ неудивительно, что не дают очень конкретного определения типа. C99 (6.2.5 10) говорит, что числа double - это подмножество long double тогда как C++03 утверждает (3.9.1 8), что long double имеет по крайней мере столько же точности, сколько double (который является то же самое, только адрес другой). В принципе, стандарты оставляют все на реализацию, так же, как и с long, int и short.

Википедия говорит, что GCC использует "80-битная расширенная точность на процессорах x86 независимо от используемого физического хранилища".

в документации GCC говорится, все на одной странице, что размер типа составляет 96 бит из-за i386 ABI, но не более 80 бит точности включено любой опцией (да? что?), также Pentium и более новые процессоры хотят, чтобы они были выровнены как 128-битные числа. Это значение по умолчанию под 64 битами и может быть включено вручную под 32 битами, что приводит к 32 битам нулевого заполнения.

время для запуска теста:

#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;
}

выход, при использовании long double, выглядит примерно так, с отмеченными цифрами постоянными, а все остальные в конечном итоге меняются по мере увеличения чисел и больше:

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

это говорит о том, что он является не 80-битное число. 80-разрядное число имеет 18 шестнадцатеричных цифр. Я вижу изменение 22 шестнадцатеричных цифр, что больше похоже на число 96 бит (24 шестнадцатеричных цифры). Это также не 128-битное число, так как 0xdeadbeef не трогается, что согласуется с sizeof возвращение 12.

вывод __int128 похоже, это действительно просто 128-битное число. Все биты в конце концов переворачиваются.

компиляция с -m128bit-long-double тут не выровнять long double до 128 бит с 32-битным нулевым заполнением, как указано в документации. Он не использует __int128 либо, но действительно, кажется, выравнивается до 128 бит, заполнение со значением 0x7ffdd000(?!).

далее LDBL_MAX, кажется, работает как +inf как long double и __float128. Добавление или вычитание числа, например 1.0E100 или 1.0E2000 to / from LDBL_MAX результаты в том же битовом шаблоне.
До сих пор я считал, что foo_MAX константы должны были содержать наибольшее представимое число, которое не +inf (по-видимому, это не так?). Я также не совсем уверен, как в 80-разрядное число может действовать как +inf для 128-битного значения... может быть, я просто слишком устал в конце дня и сделал что-то не так.