Raw binary(to work without OS) in D

[Jens Mueller]

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.

Jens