digitalmars.D - popcnt usage
- Todd VanderVeen (48/48) Dec 23 2013 First, let me say thanks for the addition of the popcnt inline
- Todd VanderVeen (19/19) Dec 23 2013 I retract my second concern. I misread a purity error for a CTFE
- Todd VanderVeen (6/6) Dec 23 2013 Actually, I dropped the static if in my example and traded one
- Iain Buclaw (2/4) Dec 23 2013 It may have side effects, or no one thought about making it pure.
- Iain Buclaw (4/33) Dec 23 2013 There's no way to do this at compile time, other than assume that
- Marco Leise (7/47) Dec 23 2013 You _could_ export the the target CPU as some built-in enum.
- Marco Leise (7/47) Dec 23 2013 Oh and if I remember correctly the popcnt intrinsic in GDC is
- Kai Nacke (6/55) Jan 02 2014 With ldc2 you can use -mattr=+popcnt to use popcnt instruction
First, let me say thanks for the addition of the popcnt inline assembler opcode. I had placed a project on hold until it was available. I look forward to using D again. I determined this instruction was available after some experimentation as its not documented on the inline assembler page. uint popcnt (ulong bits) { asm { mov RAX, bits ; popcnt RAX, RAX ; } } Mention is made in the documentation of SSE4.2 support but I understand popcnt and lzcnt aren't really considered part of this instruction set as they aren't register based. If I were to submit a pull request to address the documentation, how would you prefer this is represented, simply as additions to the opcode table or annotated that they were implemented alongside SSE4.2? Both? A second concern is whether it is possible to determine the availability of this instruction at compile time. I want to do something like the following in a custom popcnt method: version(X86_64) { static if (hasPopcnt()) { asm { ... performant assembly version } } else { ... slower procedural version } } But the miscellaneous features of core.cpuid are not available for conditional compilation. Is there an undocumented version label that could be used to this end? Is my only option to pass a version flag on the command line? version(X86_64) { version(Has_Popcnt) { asm { ... performant assembly version } } else { ... slower procedural version } } This is workable, but it would be nice if these finer architectural distinctions were available for conditional compilation without the need for the extra external configuration.
Dec 23 2013
I retract my second concern. I misread a purity error for a CTFE error. This does work as expected. import core.cpuid: hasPopcnt; /// Returns the number of bits which are set. uint popcnt(ulong bits) nothrow { version(X86_64) { if(hasPopcnt()) { asm { .... } } else { ... } } } Is there any reason that core.cpuid.hasPopcnt() cannot be made pure? Hopefully, calling it won't change my processor :)
Dec 23 2013
Actually, I dropped the static if in my example and traded one problem for another. As the static variables of core.cpuid are not accessible at compile time, I would like to emulate the cpu interrogation done there, but I see that asm statements are disallowed in CTFE. Is versioning the only option here?
Dec 23 2013
On 23 December 2013 20:18, Todd VanderVeen <tdvanderveen gmail.com> wrote:Is there any reason that core.cpuid.hasPopcnt() cannot be made pure? Hopefully, calling it won't change my processor :)It may have side effects, or no one thought about making it pure.
Dec 23 2013
On 23 December 2013 16:47, Todd VanderVeen <tdvanderveen gmail.com> wrote:First, let me say thanks for the addition of the popcnt inline assembler opcode. I had placed a project on hold until it was available. I look forward to using D again. I determined this instruction was available after some experimentation as its not documented on the inline assembler page. uint popcnt (ulong bits) { asm { mov RAX, bits ; popcnt RAX, RAX ; } } Mention is made in the documentation of SSE4.2 support but I understand popcnt and lzcnt aren't really considered part of this instruction set as they aren't register based. If I were to submit a pull request to address the documentation, how would you prefer this is represented, simply as additions to the opcode table or annotated that they were implemented alongside SSE4.2? Both? A second concern is whether it is possible to determine the availability of this instruction at compile time. I want to do something like the following in a custom popcnt method: version(X86_64) { static if (hasPopcnt()) { asm { ... performant assembly version } } else { ... slower procedural version } }There's no way to do this at compile time, other than assume that D_InlineAsm_X86_64 imples popcnt, or do a runtime check to determine the correct path to take.
Dec 23 2013
Am Mon, 23 Dec 2013 23:46:11 +0000 schrieb Iain Buclaw <ibuclaw gdcproject.org>:On 23 December 2013 16:47, Todd VanderVeen <tdvanderveen gmail.com> wrote:You _could_ export the the target CPU as some built-in enum. Like in the old days where it resulted in Pentium Pro and K6 builds. -- MarcoFirst, let me say thanks for the addition of the popcnt inline assembler opcode. I had placed a project on hold until it was available. I look forward to using D again. I determined this instruction was available after some experimentation as its not documented on the inline assembler page. uint popcnt (ulong bits) { asm { mov RAX, bits ; popcnt RAX, RAX ; } } Mention is made in the documentation of SSE4.2 support but I understand popcnt and lzcnt aren't really considered part of this instruction set as they aren't register based. If I were to submit a pull request to address the documentation, how would you prefer this is represented, simply as additions to the opcode table or annotated that they were implemented alongside SSE4.2? Both? A second concern is whether it is possible to determine the availability of this instruction at compile time. I want to do something like the following in a custom popcnt method: version(X86_64) { static if (hasPopcnt()) { asm { ... performant assembly version } } else { ... slower procedural version } }There's no way to do this at compile time, other than assume that D_InlineAsm_X86_64 imples popcnt, or do a runtime check to determine the correct path to take.
Dec 23 2013
Am Mon, 23 Dec 2013 23:46:11 +0000 schrieb Iain Buclaw <ibuclaw gdcproject.org>:On 23 December 2013 16:47, Todd VanderVeen <tdvanderveen gmail.com> wrote:Oh and if I remember correctly the popcnt intrinsic in GDC is somewhat slow in emulation mode. No biggie, I just got reminded. -- MarcoFirst, let me say thanks for the addition of the popcnt inline assembler opcode. I had placed a project on hold until it was available. I look forward to using D again. I determined this instruction was available after some experimentation as its not documented on the inline assembler page. uint popcnt (ulong bits) { asm { mov RAX, bits ; popcnt RAX, RAX ; } } Mention is made in the documentation of SSE4.2 support but I understand popcnt and lzcnt aren't really considered part of this instruction set as they aren't register based. If I were to submit a pull request to address the documentation, how would you prefer this is represented, simply as additions to the opcode table or annotated that they were implemented alongside SSE4.2? Both? A second concern is whether it is possible to determine the availability of this instruction at compile time. I want to do something like the following in a custom popcnt method: version(X86_64) { static if (hasPopcnt()) { asm { ... performant assembly version } } else { ... slower procedural version } }There's no way to do this at compile time, other than assume that D_InlineAsm_X86_64 imples popcnt, or do a runtime check to determine the correct path to take.
Dec 23 2013
On Monday, 23 December 2013 at 16:47:32 UTC, Todd VanderVeen wrote:First, let me say thanks for the addition of the popcnt inline assembler opcode. I had placed a project on hold until it was available. I look forward to using D again. I determined this instruction was available after some experimentation as its not documented on the inline assembler page. uint popcnt (ulong bits) { asm { mov RAX, bits ; popcnt RAX, RAX ; } } Mention is made in the documentation of SSE4.2 support but I understand popcnt and lzcnt aren't really considered part of this instruction set as they aren't register based. If I were to submit a pull request to address the documentation, how would you prefer this is represented, simply as additions to the opcode table or annotated that they were implemented alongside SSE4.2? Both? A second concern is whether it is possible to determine the availability of this instruction at compile time. I want to do something like the following in a custom popcnt method: version(X86_64) { static if (hasPopcnt()) { asm { ... performant assembly version } } else { ... slower procedural version } } But the miscellaneous features of core.cpuid are not available for conditional compilation. Is there an undocumented version label that could be used to this end? Is my only option to pass a version flag on the command line? version(X86_64) { version(Has_Popcnt) { asm { ... performant assembly version } } else { ... slower procedural version } } This is workable, but it would be nice if these finer architectural distinctions were available for conditional compilation without the need for the extra external configuration.With ldc2 you can use -mattr=+popcnt to use popcnt instruction and -mattr=-popcnt to use the emulation. Regards, Kai
Jan 02 2014