• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (45/45) Apr 04 2005 I looked up the size and alignment of the

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

I looked up the size and alignment of the
"long double" (IEEE 754 Extended Double),
at least if you count the default ABIs ?
(it is usually overridable at your peril)

It tends to vary a lot between CPU and OS...


Here is the table:

C "long double" / D "real"
==========================

PPC (64-bit FP registers)

                           Size    Align
Mac OS X                    8     4/8
Linux PPC                   8     4/8
Linux PPC64*                8       8
IBM AIX "Double-Double"*   16      16

X86 (80-bit FP registers)

Windows                    10       2
Linux X86                  12       4
Linux X86_64               16      16

SPARC (64-bit FP registers)

"libcx" library (slow)     16      16
2 hardware regs (fast)     16      16


Note that both standard X86 and standard PPC
system ABIs put these "extended doubles" at
sub-optimal alignments, due to compatibility.
(the 32-bit ABIs, that is, not the 64-bit ABI)

(Both the Pentium and above and the PowerPC G3
and above, prefers that their 80-bit / 64-bit
registers are stored at "bigger" boundaries:
i.e. 128-bit and 64-bit aligned, respectively)


Neither implementation has a "real" 16-byte FP,
the X86 just stores a 80-bit with 0-padding and
the PPC uses 2 doubles with different magnitudes.
(does *not* follow the IEEE 754 Standard, AFAIK)

I don't have any SPARC, but I read that using
128-bit long doubles can be like 10 times slower...
(if they are being implemented in a software lib)
So they also look unusable for D's "real" type ?


Might as well wait until we get real Quad "FPUs"...
(before trying to support a 128-bit floating point)

--anders

* PS.
   PPC64 ABI v1.4.1 uses 32-bit long, 64-bit double
   and 64-bit long double, ABI v1.7.1 uses a 64-bit
   long, 64-bit double and 128-bit "AIX" long double.
   See http://www.linuxbase.org/spec/ELF/ppc64/