Don Clugston:

> 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 ucents are in D specs and I think their name is already somewhere in the compiler. While "quadruple" (or "qfloat") is not yet in D specs:

http://en.wikipedia.org/wiki/Quadruple_precision

Bye,
bearophile

On Thursday, 28 June 2012 at 15:28:10 UTC, Don Clugston wrote:
> There's an oddity, though: the type of X.significand would be dependent on the type of X […]

I don't think this is a problem at all – for example, the type of T.init depends on T as well…

David

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

On 22 June 2012 07:35, Walter Bright <newshound2@digitalmars.com> wrote:
> On 6/21/2012 11:07 PM, Mehrdad wrote:
>>
>> On Thursday, 21 June 2012 at 19:44:40 UTC, Walter Bright wrote:
>>>
>>> On 6/21/2012 9:39 AM, Alex wrote:
>>>>
>>>> is it possible to use D to write code to work without OS? like i do it with gcc.
>>>
>>>
>>> Sure. But you'll need to thoroughly understand how the D runtime startup
>>> code
>>> works, so you can adjust as necessary.
>>
>>
>> Good luck getting the C-runtime part of the "D runtime" right..
>
>
> It's not that hard. But there's a lot of detail to learn & take care of.
>

Wouldn't it be useful if the compiler had diagnostics for all implicit allocations it makes (ie: closures, array literals)?  Similar to that of the -vtls switch. These such things you may want to avoid in a freestanding environment (no link to C runtime).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 28 June 2012 at 14:35:24 UTC, 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

.exp might potentially lead to confusion regarding std.math.exp with UFCS in place. Not that this would be a huge deal, but since new property would be used only very rarely anyway, I don't think going for a longer name like .exponent or even rawExponent/exponentBits/… would be a problem.

David

On Thursday, 28 June 2012 at 13:39:54 UTC, bearophile wrote:
> Paulo Pinto:
>
>> as Metro is also native code.
>
> Are you sure? Do you have a reference on this?
>
> Bye,
> bearophile

The huge amount of documentation made available at BUILD time, plus Windows 8 to play with?

WinRT (aka Metro) is COM based.

Instead of me dumping a list of links, what you want to know exactly?

--
Paulo

On Jun 28, 2012, at 9:45 AM, Iain Buclaw wrote:
> 
> Wouldn't it be useful if the compiler had diagnostics for all implicit allocations it makes (ie: closures, array literals)?  Similar to that of the -vtls switch. These such things you may want to avoid in a freestanding environment (no link to C runtime).

Yes it would.  I guess the question is how to expose this.  Generally speaking though, array append type operations allocate, AA insertions allocate, and non-scope delegate use allocates.  I think that's it.

Paulo Pinto:

> The huge amount of documentation made available at BUILD time, plus Windows 8 to play with?
>
> WinRT (aka Metro) is COM based.
>
> Instead of me dumping a list of links, what you want to know exactly?

OK. No need for a list.

Bye,
bearophile

On 28 June 2012 18:02, Sean Kelly <sean@invisibleduck.org> wrote:
> On Jun 28, 2012, at 9:45 AM, Iain Buclaw wrote:
>>
>> Wouldn't it be useful if the compiler had diagnostics for all implicit allocations it makes (ie: closures, array literals)?  Similar to that of the -vtls switch. These such things you may want to avoid in a freestanding environment (no link to C runtime).
>
> Yes it would.  I guess the question is how to expose this.  Generally speaking though, array append type operations allocate, AA insertions allocate, and non-scope delegate use allocates.  I think that's it.

>From a user perspective?  A switch that has a less ugly than
-vimplicit_library_calls.  Which spurts out messages like:

"Function %s builds a closure", func

or

"Expression %s makes implicit allocation call to %s", expr, func


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Iain Buclaw:

>>From a user perspective?  A switch that has a less ugly than
> -vimplicit_library_calls.  Which spurts out messages like:
>
> "Function %s builds a closure", func

http://d.puremagic.com/issues/show_bug.cgi?id=5070

Bye,
bearophile