I have a rather interesting issue. When compiling a Win32 executable project in MSVS2010, it seems the compiler is adding a function call to IsProcessorFeaturePresent (kernel32) inside my custom implementation of memcpy. I have disassembled the executable and found it is calling IsProcessorFeaturePresent with 0xA (PF_XMMI64_INSTRUCTIONS_AVAILABLE) and then forking the code based on the return value to either normal x86 instructions or the MMX 64-bit optimized instructions. How can I stop this from happening? It is also interesting to note that this type of processor feature check happens with the MSCRT implementation of memcpy() as well hence my reason for trying a custom implementation.
If you explicitly enable SSE support, I would assume VS no longer does the check. Google says the parameter for that is /arch:SSE. On the downside, this causes your program to no longer run on CPUs that don't support SSE.
I'd like to totally disable SSE support and stick to strict 80x86 instructions which is guaranteed to run on any win32/win64 system. Is there a way to do this?
I had to recode/redefine memcpy, memset, strcpy, strlen, strcmp. Apparently some of these functions when compiled with optimization, the compiler will insert processor feature checking code to run MMX/SSE/etc/etc as a speed optimization. What a PITA.
Another interesting oddball feature of MSVC++2010 is that it will insert a new segment into your PE file called .CRT, which is a 0x200 sized segment containing nothing but a DWORD variable that stores the return value from IsProcessorFeaturePresent.