I am using some intrinsic function in my driver code. Initially i tested this function in user space program and the code was working as expected. Then i moved the function to the driver module.
In the driver build it is throwing compiler error for this function.
error C2164: ‘_**mm256_insert_epi64’: intrinsic function not declared
**
In the user space i am seeing the defintion in the file C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.25.28610\include*immintrin.h*. #if defined(_M_X64)
extern __m256i __cdecl _mm256_insert_epi64(__m256i /* dst /, __int64 / src /, const int / index */);
But somehow this function definition is not visible to driver module. Any idea why it is failing.
The obvious question is, are you building a 64-bit driver? That instruction is 64-bit only.
I notice that the mm256 variants of insert_epiXX are present in the VS19 version of immintrin.h, but they are not defined in the SDK/WDL versions of immintrin.h. I don’t know whether a WDK build will use the compiler-local version.
The cost of a compiler bug is much higher in a kernel driver than in a user-mode application. The WDK team needs extra assurance that cutting-edge compiler features are well-tested and well-established. As a result, the WDK tends to be slow in adopting new edge compiler features.
If it is truly a compiler intrinsic, nothing is stopping you from adding the prototype in your source code, assuming the project file has enabled the AVX extensions. Do you realize you have to save and restore the AVX registers when you use them in a kernel driver?
I am trying to use these source code in my driver. Since this is developed my MS and other research people, i hope they should have handled the AVX register.
I am trying to use these source code in my driver. Since this is developed my MS and other research people, i hope they should have handled the AVX register.
Hmmmm… I don’t think their code was written to run in kernel-mode, was it? What Mr. Roberts was referring to is a kernel-mode only requirement.
To state the obvious, that so often gets ignored: Programming in kernel-mode is not like programming in user-mode. It’s never a matter of grabbing some code you don’t understand, hacking the shit out of it until you suspect that it does what you want, and then moving on. That works for, you know, WinForms and C# and SQL queries… but this is a serious recipe for fucking up the system that’s running your code. Sometimes in an obvious way; Sometimes subtly.
I confirmed with the developer of the source code. They are able to compile it for kernel mode but they didn’t share any reference. Since they have portable C implementation, i am trying to compile it for my driver. As you mentioned there will be lot of issues when using user space code to kernel driver. But i want to see whether the code works or not in the driver module…
I am not aware of the complexity involved in using AVX and AVX2 instruction sets. For time being i will avoid using their implementation that has AVX and AVX2 dependency. They have portable C implementation also, let me use this for my work.
To state the obvious, that so often gets ignored: Programming in kernel-mode is not like programming in user-mode.
It’s never a matter of grabbing some code you don’t understand, hacking the shit out of it until you suspect that it does what you want,
and then moving on. That works for, you know, WinForms and C# and SQL queries… but this is a serious recipe for fucking
up the system that’s running your code. Sometimes in an obvious way; Sometimes subtly.
Well, in order to work the way described above, the code in question has to be totally environment-agnostic, which means that it cannot call a SINGLE function that it does not implement itself. Otherwise, it simply has no chance of ever getting compiled, in the first place.
There are not THAT many problems that may be approached this way,right. Therefore, the code that may be used this way is most likely to implement some generic CS algorithm like compression,encryption, tree operations, etc,etc,etc. In other words, it is quite unlikely to pose any problem as long as you use it in the right context. For example, if the target code deals with a tree and you want to use it in Windows kernel, it is your responsibility to ensure that an access to this tree is properly synchronised, that no part of this tree may be located in a pageable memory if you intend to access it at elevated IRQL, etc,etc,etc.
I would rather apply your statement to the various attempts of “porting” a code written for the OS ABC to the OS XYZ, by means of implementing some compatibility layer, despite the HUGE architectural differences between the OSes in question that this layer just cannot hide. The very first example that comes up to my mind is ZFS on Windows project (check their posts to this NG for more info) …