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

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

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.

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.

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

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

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

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

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

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 to core.cpuid.avx (http://dlang.org/phobos/core_cpuid.html#.avx).

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

Thanks for the input.

Joseph