Another take on decimal data types

[kdevel]

On Sunday, 14 January 2018 at 12:35:43 UTC, rumbu wrote:
> On Sunday, 14 January 2018 at 11:44:39 UTC, kdevel wrote:
>> On Sunday, 14 January 2018 at 07:20:26 UTC, rumbu wrote:
>>> On Saturday, 13 January 2018 at 22:51:18 UTC, kdevel wrote:
>>>> [...]
>>>
>>> Can you please tell me on your system what are the values for 
>>> real.sizeof and real.mant_dig?
>>
>> They are 12 and 64 (-m32) and 16 and 64 (-m64).
>>
>
> This is curious. Because the only documented real type with a 
> 64-bit mantissa is the 80-bit Intel Extended Precision format 
> with a unique sizeof of 10 (and not 12 or 16).

sizeof returns the in-memory size (at least in C and C++) which 
is subject to alignment constraints.  32-bit mode typically 
requires 4-byte aligned access (96 bit = 12 byte) while 64-bit 
requires 8-byte alignment (128 bit = 16 bytes) for optimal 
performance. Cf. e.g. p. 28 of "SYSTEM V APPLICATION BINARY 
INTERFACE Intel386" (long double)

http://www.sco.com/developers/devspecs/abi386-4.pdf

and p. 12 of "System V Application Binary Interface AMD64 
Architecture Processor Supplement"

https://www.uclibc.org/docs/psABI-x86_64.pdf

> Actually, real80 is the only type I'm supporting in the 
> library, any other real type is converted to double. This will 
> explain some loss of precision.

Agreed.

> Do you have more information about the real type on you system, 
> because on mine (Windows), real.sizeof is always 10, 
> irrespective of -m32 or -m64.
>
> Mantissa will be easy to extract being 64-bit, but I don't know 
> the exact layout of your real type to extract the exponent.

Assumed that your machine has a X86_64 cpu real = long double is 
the 80-bit extended precision format. I suppose you are running 
windows and it may be that the Window ABI stores these reals 
16-bit (2-byte) aligned. In this case there will be no padding. 
But I have not found info on this topic.