Make inline asm in x64-bit projects.
Hi, thanks for the suggestion.
You can currently write a function in x64 assembly language and use MASM to create an object file and then use in in your C/C++ application.
-Visual C++ Team
David Ludwig commented
MASM is only supported on Windows.
The lack of inline assembly helps preclude one from writing assembly-laden, C/C++ code, that works across different compilers and operating systems (that share common, host CPUs).
vli va commented
Please don't refuse @Visual Studio Team (Product Team, Microsoft Visual Studio)
Nikolai Vorontsov commented
For me it sound like - we can use other compiler at all. The greatest advantage of Visual Studio was neat integration of editor/compiler and debugger. With the time being it becomes worse and worse. So, what's the advantage for use to use Studio? Average compiler, clumsy IDE, absence of common features (x64 inline assembler), user response rejection... It's pity, I've been with MS OS and tools for 20 years, but now I feel it's time to leave. I wont pay for THAT. If I have to use **** - at least I can get the **** for free, I don't want to pay for ****.
This is a silly response. I can also currently write C++ in notepad and compile using command line, but I still for some reason use VS
Paul M commented
The only use case I know of is due to VS not supporting "computed gotos" when writing a VM/interpreter. If VS supported & on labels then falling back to inline ASM wouldn't be required.
there are no reasons that compiler not support it
Gaetano Cazzetta commented
Reverse engineering and function hooking in particular would benefit from a lot, not to mention the Detours library has got X64 support.
Anton K commented
We need it to port old code to 64 bit.
Malcolm Windham commented
Driver development, other convenience in applications. Another similar 64 bit inline has votes, too.
Albert van Peppen commented
I have currently some assembly code for accessing hardware on the lowest level in order to get the most of the performance possible.
In earlier versions (VC8 and before) most of this was written as inline code which was much easier to maintain.
The VC IDE lacks a proper .asm editor so that is not very helpfull as well.
The assembly code I use is for accessing hardware without intervention of the Windows layers, which are buggy at some points, moving data all over in memory, are sometimes shielded from the C++ developer and most important: they ar at least 100 times slower as my direct approach in assembly.
Also don't forget the fact that some Windows API are changing some data before passing them to the C++ caller (which is a bug in my opinion since the first time this was used).
I know that Windows is trying to protect itself against all kind of threats but sometimes the developer needs full control, even if this means the application needs to access ring 0 (in a safe way, but that's up to the developer to do)..
Janno Ossaar commented
There are many worthwhile places to use this:
1. Whenever there is a need to have few optimized functions it is easier to maintain code by writing these as "naked" C/C++ functions in same code module instead of having separate ".asm" file in project (much nicer for cross platform projects, since then one can just ifdef gcc parts).
2. needing parts of function to have inline code pieces that can later be identified by executable post processor and then replaced with dynamically generated code (allows signature + filler to be replaced with something meaningful - useful for software protection and obfuscation).
3. whenever needing to access specific CPU supported instruction that isn't covered by available intrinsics - thus allowing more optimal results than writing it as C/C++ that compiler never (might in future) optimizes to same level.
When I posted this, I needed it; intrinsics only got me so far. For the projects I've been since 2013, I haven't needed it.
Trying to port openblas to msvc is near impossible without this.
Anonymous Coward commented
I'm with Ben Voigt on this. Intrinsics are far better. If there are specific things that can't be done with the current intrinsics, the answer is to add more. Create User Voice suggestions for whatever you think is missing! It also wouldn't hurt if Microsoft did a better job documenting the available intrinsics (e.g. don't send people to Intel's web site!).
RE: "ICC, gcc and clang support this. MSVC is the only odd one out."
First, what you really have is gcc supporting it. The other compilers you cite are intended to be "gcc compatible". That isn't a goal for MSVC (nor should it!). It goes both ways. gcc doesn't support the MSVC syntax for x86 inline assembler.
Second, the fact that something is widespread or popular doesn't mean it's good for you. Cancer is widespread, and McDonald's French Fries are popular.
inline asm is used a lot in BLAS libraries which makes msvc compatibility difficult.
It would be nice if the biggest hurdle was simply adding an #ifdef and changing the syntax where needed instead of having to do a large portion more.
ICC, gcc and clang support this. MSVC is the only odd one out. It really is a shame!
Ben Voigt commented
If there are opcodes which have no corresponding intrinsic, then let's ask for a more complete set of intrinsics...
Intrinsics are a lot nicer from an optimization standpoint, because they play nicely with register allocation, subexpression elimination, etc. Inline asm kills optimization.
Many opcodes are missing from instrinsics. Very frustrating and very important. email@example.com
Scott Bruno commented
I'll add a vote to this one. @Ben and others, try to remember that just because you might not use something doesn't mean no one else can or will benefit from it.
Yes, bring back inline assembly. The beauty of c++ is the ability to have full control.
But for C++ x64-projects inline asm needed 100%