I suggest you ...

assembler

Make inline asm in x64-bit projects.

825 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Roman shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    24 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • David Ludwig commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        Please don't refuse @Visual Studio Team (Product Team, Microsoft Visual Studio)

      • Nikolai Vorontsov commented  ·   ·  Flag as inappropriate

        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 ****.

        unhappy customer.

      • shoosh commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Gaetano Cazzetta commented  ·   ·  Flag as inappropriate

        Reverse engineering and function hooking in particular would benefit from a lot, not to mention the Detours library has got X64 support.

      • Albert van Peppen commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Joe commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous Coward commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Scott Bruno commented  ·   ·  Flag as inappropriate

        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.

      • anon commented  ·   ·  Flag as inappropriate

        Yes, bring back inline assembly. The beauty of c++ is the ability to have full control.

      ← Previous 1

      Feedback and Knowledge Base