www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compile-time evaluation of real expressions?

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 06 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Jan 06 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 06 2012
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jan 06 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Jan 06 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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)
Jan 06 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 06 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 06 2012
parent Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 06 2012
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 07-01-2012 01:31, H. S. Teoh wrote:

 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


Executing asm at compile time is also a security risk.

-- 
- Alex
Jan 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 06 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 07, 2012 04:49:27 Timon Gehr wrote:

 On 01/07/2012 12:37 AM, Jonathan M Davis wrote:

 On Saturday, January 07, 2012 00:03:39 Alex R=C3=B8nne Petersen wro=




te:

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


=20
 Yeah, several functions in std.math use inline assembly. So, for th=




em 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 ma=




y or

 may not be planned and may or may not be reasonable), or those
 functions need another branch (using __cfte in an if condition) whi=




ch

 doesn't use assembly. Or I suppose that if the extra check for __ct=




fe

 isn't considered particularly acceptable (after all, they're alread=




y

 using assembly)  [snip.]


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


Ah, good point - though depending on what the compiler does, that may o=
nly be=20
the case with -O. But anyone who really cares about that level of perfo=
rmance=20
would be compiling with -O anyway.

- Jonathan M Davis
Jan 06 2012