Raw binary(to work without OS) in D

[Don Clugston]

On 28/06/12 18:36, Jens Mueller wrote:
> Don Clugston wrote:
>> On 28/06/12 17:00, Jens Mueller wrote:
>>> Andrei Alexandrescu wrote:
>>>> On 6/28/12 10:07 AM, Roman D. Boiko wrote:
>>>>> On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
>>>>>> I think just exposing them via .sig and .exp might be the way to go?
>>>>>
>>>>> sig is easy to confuse with sign
>>>>
>>>> .mantissa and .exp
>>>
>>> Letting the compiler define these properties is a solution. I thought
>>> Don is looking for something more general. But maybe this isn't needed
>>> here. Don't know. But using mantissa should be discouraged.
>>> I suggest calling them
>>> .significand and .exponent
>>>
>>> significand is preferred over mantissa by IEEE FP committee. I think
>>> it's fine to spell them out. There won't be much code using them anyway.
>>>
>>> Jens
>>
>>
>> Yes, adding new properties would be the easiest way from a CTFE
>> perspective; that way, they are endian-ness independent. It's a bit
>> niche, but then again adding a special case for this in CTFE is
>> niche as well. Maybe it would be the best approach.
>
> Sounds good then.
>
>> With naming, I'm included to agree, but the funny thing is that we
>> have X.mant_dig as the number of digits in the significand.
>
> You could add a deprecated alias to X.mant_dig and provide a new name.
> We should adopt IEEE's vocabulary where possible.
>
>> There's an oddity, though: the type of X.significand would be
>> dependent on the type of X (and for the non-existent quadruple
>> float, it would be non-existent ucent type!)
>
> But this is no problem, is it?
>
>> Would it include the implicit bit of an 80-bit x87 real (the silly bit)?
>
> Not sure what the silly bit is. You mean the bit that is implicitly
> always 1, don't you? mant_dig says 24 for a float. Means it is included
> when counting the bits. Then for consistency it should be included.

Yes, the implicit bit. For float and double it isn't present, but it's 
there for 80bit x87 and 68K reals.
But it would not be present for quadruple types. I'm not sure if it's 
always present on Itanium 80-bit reals.

It's included in the 80-bit reals only for historical reasons -- it 
seemed like a good idea at the time. It allowed an optimisation for a 
long-obsolete algorithm.