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