Linked by David Adams on Sun 14th Aug 2011 22:41 UTC, submitted by subterrific
Thread beginning with comment 485027
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Yet another standard...
by gilboa on Mon 15th Aug 2011 09:02
in reply to "RE[5]: Yet another standard..."
Now if you still believe you're so pro that you can outsmart the compiler's optimization stages, then surely moving your code to an .asm file and doing the x64 function prolog should be a trivial one-time problem, right?
*Sigh*
10 words, small letters:
memory barriers, lock variants, special ops, per-cpu/platform variant.
- Gilboa
Edited 2011-08-15 09:04 UTC




Member since:
2009-12-10
It is very simple really. Microsoft decided that porting the in-line assembly code to support 64 bit was too much work. So they decided not to bother since in-line assembly really complicates the optimization stages of the compiler. And since the days when in-line assembly was "invented", compiler vendors realized that creating intrinsic functions was a much better solution.
The intrinsic functions have the key advantage that they can be optimized further by the compiler, which means things like register management and memory locations for variables can still be controlled by the usual optimization stages.
This means that some SSE2 code that is written with assembly will have to be re-written for x64 if you want to take advantage of the new set of registers, while the version using intrinsics will simply have to be recompiled. The intrinsic version also just works on GCC, Intel's compiler, MINGW, LLVM. This is also not the case for assembly.
Now if you still believe you're so pro that you can outsmart the compiler's optimization stages, then surely moving your code to an .asm file and doing the x64 function prolog should be a trivial one-time problem, right?