www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inline assembly and CTFE

reply "Joseph Cassman" <jc7919 outlook.com> writes:
As of DMD 2.063.2 it looks to me like inline assembly language 
blocks are not usable in compile-time code. For example, the 
following code

   void main() {
     enum a = abc();
   }
   ulong abc() {
     asm { mov RAX,1; }
     return 1;
   }

will produce the error "Error: asm statements cannot be 
interpreted at compile time".

Are there plans to eventually support the use of asm blocks in 
CTFE?

If it were possible then I could use such a function in a static 
if test. What I am looking to do is use a function that calls 
CPUID (etc.) in a static if statement to determine which code to 
generate, somewhat like the following.

   bool isAVXPossible() { asm { ... use CPUID, etc. ... } }
   void foo() {
     static if(isAVXPossible()) {
       asm { ... generate AVX version ... }
     else {
       asm { ... generate non AVX version ... }
     }
   }

I cannot use version(D_SIMD) because I need some more specificity 
in the versioning. Similarly, version(X86) and version(X86_64) 
are convenient but I would like to be more exact. Also, I tried 
the functionality in core.cpuid but it also seems only able to 
execute at run-time. When trying to use it in a static if 
statement I get the error "Error: static variable xfeatures 
cannot be read at compile time".

Any ideas on how to implement isAVXPossible() and its related 
functionality without using a runtime test are appreciated.

Thanks

Joseph
Oct 03 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 3 October 2013 at 22:25:27 UTC, Joseph Cassman wrote:

 Are there plans to eventually support the use of asm blocks in 
 CTFE?


No.


 Any ideas on how to implement isAVXPossible() and its related 
 functionality without using a runtime test are appreciated.


What would you even want the function to return in the first 
place? The CPU features you can use obviously depend on the 
specific CPU the executable will run on, so the answer can't 
generally by known at compile time.

Do you want to base your decision on the CPU of the build host? 
Or are you looking for an efficient way to implement the runtime 
check?

David
Oct 03 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 3 October 2013 at 22:30:24 UTC, David Nadlinger 
wrote:

 On Thursday, 3 October 2013 at 22:25:27 UTC, Joseph Cassman 
 wrote:

 Are there plans to eventually support the use of asm blocks in 
 CTFE?


 No.


 Any ideas on how to implement isAVXPossible() and its related 
 functionality without using a runtime test are appreciated.


 What would you even want the function to return in the first 
 place? The CPU features you can use obviously depend on the 
 specific CPU the executable will run on, so the answer can't 
 generally by known at compile time.

 Do you want to base your decision on the CPU of the build host? 
 Or are you looking for an efficient way to implement the 
 runtime check?

 David


And if decision is based on build host it makes much more sense 
to incorporate check into the build process and supply results to 
main program in a form of manual version. At least in that way it 
will be perfectly clear that this is intended behavior.
Oct 03 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 And if decision is based on build host it makes much more sense 
 to incorporate check into the build process and supply results 
 to main program in a form of manual version. At least in that 
 way it will be perfectly clear that this is intended behavior.


Static CPU introspection could be handy sometimes, if you want to 
run the code in the same system you have used to compile the 
code, and avoid run-time CPU tests.

Bye,
bearophile
Oct 03 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 3 October 2013 at 23:21:56 UTC, bearophile wrote:

 Static CPU introspection could be handy sometimes, if you want 
 to run the code in the same system you have used to compile the 
 code, and avoid run-time CPU tests.


The reason why this wouldn't be particularly useful with DMD 
right now is that its backend doesn't make use of any 
"non-generic" instructions by default, and as such it is lacking 
the command line flags, …  to control what CPU to target.

And the cases where just optimizing for the host CPU by default 
is a good idea are rather rare – we LDC guys learned that the 
hard way when we accidentally had the equivalent of 
"-march=native" for GCC enabled by default without anybody 
knowing.

David
Oct 03 2013
prev sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 3 October 2013 at 22:30:24 UTC, David Nadlinger 
wrote:

 What would you even want the function to return in the first 
 place? The CPU features you can use obviously depend on the 
 specific CPU the executable will run on, so the answer can't 
 generally by known at compile time.

 Do you want to base your decision on the CPU of the build host? 
 Or are you looking for an efficient way to implement the 
 runtime check?

 David


Good questions. Yeah, the answer can't be generally known at 
compile time. But can be interesting in the specific case (i.e. 
when I can control both the build machine and the one it will 
eventually run on). The function in the example is a flag similar 


Was mainly looking for some feedback on the plans for the scope 
of CTFE in regards to assembly language.

Thanks for the input.

Joseph
Oct 03 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/3/2013 3:25 PM, Joseph Cassman wrote:

 As of DMD 2.063.2 it looks to me like inline assembly language blocks are not
 usable in compile-time code. For example, the following code

    void main() {
      enum a = abc();
    }
    ulong abc() {
      asm { mov RAX,1; }
      return 1;
    }

 will produce the error "Error: asm statements cannot be interpreted at compile
 time".

 Are there plans to eventually support the use of asm blocks in CTFE?


No. Simulating a CPU is way, way beyond its charter.



 If it were possible then I could use such a function in a static if test. What
I
 am looking to do is use a function that calls CPUID (etc.) in a static if
 statement to determine which code to generate, somewhat like the following.

    bool isAVXPossible() { asm { ... use CPUID, etc. ... } }
    void foo() {
      static if(isAVXPossible()) {
        asm { ... generate AVX version ... }
      else {
        asm { ... generate non AVX version ... }
      }
    }

 I cannot use version(D_SIMD) because I need some more specificity in the
 versioning. Similarly, version(X86) and version(X86_64) are convenient but I
 would like to be more exact. Also, I tried the functionality in core.cpuid but
 it also seems only able to execute at run-time. When trying to use it in a
 static if statement I get the error "Error: static variable xfeatures cannot be
 read at compile time".

 Any ideas on how to implement isAVXPossible() and its related functionality
 without using a runtime test are appreciated.



But you don't want a compile time test for that! You want a runtime test, as it 
should depend on what machine the program is running under, which may not at
all 
be the same one it compiled on.
Oct 03 2013
next sibling parent reply "Temtaime" <temtaime gmail.com> writes:
With LLVM it's possibly to fully remove interpreter from compiler 
and use JIT.
Oct 03 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 3 October 2013 at 23:02:18 UTC, Temtaime wrote:

 With LLVM it's possibly to fully remove interpreter from 
 compiler and use JIT.


I don't see how this is relevant to the discussion here, i.e. 
whether there are plans to support inline assembler in CTFE.

David
Oct 03 2013
prev sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 3 October 2013 at 22:40:14 UTC, Walter Bright wrote:

 Are there plans to eventually support the use of asm blocks in 
 CTFE?


 No. Simulating a CPU is way, way beyond its charter.


Good to know. Thanks.


 But you don't want a compile time test for that! You want a 
 runtime test, as it should depend on what machine the program 
 is running under, which may not at all be the same one it 
 compiled on.


Thanks for the other two comments along these lines as well. Of 
course a build script tends to take care of such considerations, 
I was looking for a way to do it as much in D as possible. And 
yes, it was for the idea of building and running on the same 
processor type.

Appreciate the input.

Joseph
Oct 03 2013