2 ms·
It's not mute or even moot. Assembly intrinsics are not enough. I've dealt with this, getting software to run in Visual Studio. The intrinsics are simply not a
by tropo 7y ago
It's not mute or even moot. Assembly intrinsics are not enough.
I've dealt with this, getting software to run in Visual Studio. The intrinsics are simply not available. You end up running code through gcc to produce assembly, then hacking up the assembly (way too much to write by hand) into a separate *.asm file for Visual Studio.
Vector stuff, if it isn't very new, is covered by intrinsics. Well, it is badly covered, with terrible failures to keep things in registers.
Once you get into exotic OS-level stuff, the intrinsics simply don't exist. The most important one is the ability to put an arbitrary byte sequence into the instruction stream. For example, suppose you wanted to add a Spectre fix to your JIT on day 1. You needed to fix a security problem, so waiting for a new release of Visual Studio isn't an acceptable option. You really truly need the ability to put weird byte sequences into the code. Visual Studio doesn't provide an intrinsic for that.
- pjmlp 7y agoFor such corner cases using MASM on day 1 until the new VC++ release isn't much of an issue.
- tropo 7y agoMASM is just an assembler, with no awareness of the C or C++ code. MASM is unable to place arbitrary bytes into the middle of functions that are written in C or C++. To fix a problem like Spectre, and generally to solve unusual problems that the compiler vendor isn't dealing with, the full capability of an inline assembler is required.
- pjmlp 7y agoSure it can, I really don't see any difference between that and a naked call with LTO, beyond the convenience of saving about a minute not having to write a prototype for the function being called and adding MASM into the build.