www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE is getting there

reply bearophile <bearophileHUGS lycos.com> writes:
With the recent rounds of improvements to the compile-time evaluation, mostly
from Don, CTFE is now able to run a significant percentage of D code. Some
problems left:


int foo1() {
    enum int[] array = [1];
    return 1;
}
int foo2() { // like map
    struct Bar {
        this(int x) {}
    }
    Bar(1);
    return 2;
}
int foo3() { // like std.math.poly
    version (D_InlineAsm_X86) {
        asm {
            nop;
        }
    } else {
        // fallback code here
    }
    return 3;
}
void main() {
    enum int f1 = foo1();
    enum int f2 = foo2();
    enum int f3 = foo3();
}



Another problem that I have not fully reduced yet:
http://d.puremagic.com/issues/show_bug.cgi?id=6934


I have recently asked regarding foo3 in D.learn. It's a bit sad case, because
there are some functions like std.math.poly that define usable fallback code,
but CTFE defines D_InlineAsm_X86 so it tries to run the assembly code, and
fails.

Bye,
bearophile
Nov 12 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 13 Nov 2011 00:38:58 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:


 With the recent rounds of improvements to the compile-time evaluation,  
 mostly from Don, CTFE is now able to run a significant percentage of D  
 code. Some problems left:


 int foo1() {
     enum int[] array = [1];
     return 1;
 }
 int foo2() { // like map
     struct Bar {
         this(int x) {}
     }
     Bar(1);
     return 2;
 }
 int foo3() { // like std.math.poly
     version (D_InlineAsm_X86) {
         asm {
             nop;
         }
     } else {
         // fallback code here
     }
     return 3;
 }
 void main() {
     enum int f1 = foo1();
     enum int f2 = foo2();
     enum int f3 = foo3();
 }



 Another problem that I have not fully reduced yet:
 http://d.puremagic.com/issues/show_bug.cgi?id=6934


 I have recently asked regarding foo3 in D.learn. It's a bit sad case,  
 because there are some functions like std.math.poly that define usable  
 fallback code, but CTFE defines D_InlineAsm_X86 so it tries to run the  
 assembly code, and fails.

 Bye,
 bearophile


D_InlineAsm_X86 is just a normal version tag and does not imply asm code,  
so it has to.
IASM functions should redirect __ctfe to their non asm fallback.
Nov 12 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Martin Nowak:


 D_InlineAsm_X86 is just a normal version tag and does not imply asm code,  
 so it has to.
 IASM functions should redirect __ctfe to their non asm fallback.


So you need two fallbaks and probably they contain the same code. So an inner
function is useful here.

------------------

I was forgetting: another thing that doesn't work yet at compile-time is
std.math.log.

Bye,
bearophile
Nov 12 2011
parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 13 Nov 2011 02:06:55 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:


 Martin Nowak:


 D_InlineAsm_X86 is just a normal version tag and does not imply asm  
 code,
 so it has to.
 IASM functions should redirect __ctfe to their non asm fallback.


 So you need two fallbaks and probably they contain the same code. So an  
 inner function is useful here.

 ------------------

 I was forgetting: another thing that doesn't work yet at compile-time is  
 std.math.log.

 Bye,
 bearophile


Yeah, as well as any exp or pow and isNaN.
Nov 12 2011
prev sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On Sun, 13 Nov 2011 01:28:54 +0100, Martin Nowak wrote:


 D_InlineAsm_X86 is just a normal version tag and does not imply asm
 code, so it has to.


D_InlineAsm_X86 is intended to be defined when an implementation supports 
inline asm for x86. The compiler, when running CTFE, does not, so it 
should not be defined.
Nov 12 2011
parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 13 Nov 2011 03:54:32 +0100, Bernard Helyer <b.helyer gmail.com>  
wrote:


 On Sun, 13 Nov 2011 01:28:54 +0100, Martin Nowak wrote:


 D_InlineAsm_X86 is just a normal version tag and does not imply asm
 code, so it has to.


 D_InlineAsm_X86 is intended to be defined when an implementation supports
 inline asm for x86. The compiler, when running CTFE, does not, so it
 should not be defined.


It must not necessarily be used to enclose asm code.

string platform()
{
   version (D_InlineAsm_X86)
     return "X86,ASM";
   else version (D_InlineAsm_X86_64)
     return "X86_64,ASM";
}

enum target = platform();
Nov 12 2011