Hi All,

As I understand it, compile-time execution *should* be able to evaluate floating-point functions, correct? Currently, I have this code:

        private static real cross_angles[6] = [
                real.nan,
                real.nan,
                real.nan,
                atan(sqrt(5)),
                PI_4,
                atan(sqrt(5)-2)
        ];

But the compiler is complaining:

/mnt/1/usr/include/d2/4.6/std/math.d:623: Error: asm statements cannot be interpreted at compile time /mnt/1/usr/include/d2/4.6/std/math.d:591: Error: cannot evaluate atan2(x,1.0e+0L) at compile time

Is this an artifact of using gdc-4.6 instead of dmd? Or are certain floating-point functions not allowed in compile-time expressions?

Thanks!

P.S. I just starting learning and using D recently -- and totally loving it.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce

On 06-01-2012 23:21, H. S. Teoh wrote:
> Hi All,
>
> As I understand it, compile-time execution *should* be able to evaluate
> floating-point functions, correct? Currently, I have this code:
>
>          private static real cross_angles[6] = [
>                  real.nan,
>                  real.nan,
>                  real.nan,
>                  atan(sqrt(5)),
>                  PI_4,
>                  atan(sqrt(5)-2)
>          ];
>
> But the compiler is complaining:
>
> /mnt/1/usr/include/d2/4.6/std/math.d:623: Error: asm statements cannot be interpreted at compile time
> /mnt/1/usr/include/d2/4.6/std/math.d:591: Error: cannot evaluate atan2(x,1.0e+0L) at compile time
>
> Is this an artifact of using gdc-4.6 instead of dmd? Or are certain
> floating-point functions not allowed in compile-time expressions?
>
> Thanks!
>
> P.S. I just starting learning and using D recently -- and totally loving
> it.
>
>
> T
>

Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE.

-- 
- Alex

On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote:
> Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE.

Yeah, several functions in std.math use inline assembly. So, for them to be able to be used at compile time, either the compiler must be expanded to be able to run asm statements at compile time (which may or may not be planned and may or may not be reasonable), or those functions need another branch (using __cfte in an if condition) which doesn't use assembly. Or I suppose that if the extra check for __ctfe isn't considered particularly acceptable (after all, they're already using assembly), then separate functions meant specifically for CTFE would be necessary. I don't know what Don's preferred approach would be, but presumably, it would be up to him since he's the primary maintainer of both CTFE and std.math.

An enhancement request for it should probably be opened: d.puremagi.com/issues

- Jonathan M Davis

On 01/06/2012 03:37 PM, Jonathan M Davis wrote:

> An enhancement request for it should probably be opened: d.puremagi.com/issues

  http://d.puremagic.com/issues/

Ali

On 07-01-2012 00:37, Jonathan M Davis wrote:
> On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote:
>> Most likely those functions are just implemented using inline assembly,
>> therefore not usable in CTFE.
>
> Yeah, several functions in std.math use inline assembly. So, for them to be
> able to be used at compile time, either the compiler must be expanded to be
> able to run asm statements at compile time (which may or may not be planned
> and may or may not be reasonable), or those functions need another branch
> (using __cfte in an if condition) which doesn't use assembly. Or I suppose
> that if the extra check for __ctfe isn't considered particularly acceptable
> (after all, they're already using assembly), then separate functions meant
> specifically for CTFE would be necessary. I don't know what Don's preferred
> approach would be, but presumably, it would be up to him since he's the
> primary maintainer of both CTFE and std.math.
>
> An enhancement request for it should probably be opened: d.puremagi.com/issues
>
> - Jonathan M Davis

Allowing asm in CTFE would probably be way more work than it's worth. You'd basically need full-blown analysis of x86 assembly plus an interpreter. Even then, x86 is not typed, so it's going to be a major pain...

-- 
- Alex

On Sat, Jan 07, 2012 at 12:49:46AM +0100, Alex Rønne Petersen wrote:
> On 07-01-2012 00:37, Jonathan M Davis wrote:
> >On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote:
> >>Most likely those functions are just implemented using inline assembly, therefore not usable in CTFE.
> >
> >Yeah, several functions in std.math use inline assembly. So, for them to be able to be used at compile time, either the compiler must be expanded to be able to run asm statements at compile time (which may or may not be planned and may or may not be reasonable), or those functions need another branch (using __cfte in an if condition) which doesn't use assembly. Or I suppose that if the extra check for __ctfe isn't considered particularly acceptable (after all, they're already using assembly), then separate functions meant specifically for CTFE would be necessary.
[...]

>From my limited experience, I'd say that having two versions of the
function is probably the least painful way to go.


[...]
> Allowing asm in CTFE would probably be way more work than it's worth. You'd basically need full-blown analysis of x86 assembly plus an interpreter. Even then, x86 is not typed, so it's going to be a major pain...
[...]

I admit I've no idea how the D compiler implements compile-time evaluation, but is it possible for the compiler to actually emit code for compile-time functions containing asm blocks and, say, execute it in a sandbox, and read the values out from the machine registers? Or does this create more problems than it solves?


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)

On 07/01/2012 00:31, H. S. Teoh wrote:
> I admit I've no idea how the D compiler implements compile-time
> evaluation, but is it possible for the compiler to actually emit code
> for compile-time functions containing asm blocks and, say, execute it in
> a sandbox, and read the values out from the machine registers? Or does
> this create more problems than it solves?

Doing this would mean you can't do cross-compilation, eg using x86 to compile for ARM. Which means you'd need to use a virtual machine for it, which is almost certainly more effort than it's worth.

-- 
Robert
http://octarineparrot.com/

On Sat, Jan 07, 2012 at 02:15:39AM +0000, Robert Clipsham wrote:
> On 07/01/2012 00:31, H. S. Teoh wrote:
> >I admit I've no idea how the D compiler implements compile-time evaluation, but is it possible for the compiler to actually emit code for compile-time functions containing asm blocks and, say, execute it in a sandbox, and read the values out from the machine registers? Or does this create more problems than it solves?
> 
> Doing this would mean you can't do cross-compilation, eg using x86 to compile for ARM. Which means you'd need to use a virtual machine for it, which is almost certainly more effort than it's worth.
[...]

But doesn't the use of asm{} already prevent cross-compilation in the first place? Or does the D compiler actually translate the instructions into the target platform? In which case, doesn't it already know enough to be able to interpret it?

I'm pretty sure I'm missing something obvious.


T

-- 
Customer support: the art of getting your clients to pay for your own incompetence.

On 07/01/2012 02:28, H. S. Teoh wrote:
> On Sat, Jan 07, 2012 at 02:15:39AM +0000, Robert Clipsham wrote:
>> On 07/01/2012 00:31, H. S. Teoh wrote:
>>> I admit I've no idea how the D compiler implements compile-time
>>> evaluation, but is it possible for the compiler to actually emit code
>>> for compile-time functions containing asm blocks and, say, execute it
>>> in a sandbox, and read the values out from the machine registers? Or
>>> does this create more problems than it solves?
>>
>> Doing this would mean you can't do cross-compilation, eg using x86 to
>> compile for ARM. Which means you'd need to use a virtual machine for
>> it, which is almost certainly more effort than it's worth.
> [...]
>
> But doesn't the use of asm{} already prevent cross-compilation in the
> first place? Or does the D compiler actually translate the instructions
> into the target platform? In which case, doesn't it already know enough
> to be able to interpret it?
>
> I'm pretty sure I'm missing something obvious.
>
>
> T
>

version(X86) asm
{
  // X86 ASM
}
else version(ARM) asm
{
  // ARM ASM
}
// etc

-- 
Robert
http://octarineparrot.com/

On 01/07/2012 12:37 AM, Jonathan M Davis wrote:
> On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote:
>> Most likely those functions are just implemented using inline assembly,
>> therefore not usable in CTFE.
>
> Yeah, several functions in std.math use inline assembly. So, for them to be
> able to be used at compile time, either the compiler must be expanded to be
> able to run asm statements at compile time (which may or may not be planned
> and may or may not be reasonable), or those functions need another branch
> (using __cfte in an if condition) which doesn't use assembly. Or I suppose
> that if the extra check for __ctfe isn't considered particularly acceptable
> (after all, they're already using assembly)  [snip.]

If the if condition is a constant, there is no runtime overhead.