IIRC, Microsoft wants you to use intrinsics because it plays better with their register coloring and code reordering optimizations.

Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.

Your code won't be appreciably faster than if you tuned it in the compiler, and after a few years the compiler will integrate new instructions while your assembly just gets stale.

> Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.

So there are reasons to write code in assembly language.

OK, there's no reason for YOU to write code in assembly.

For me, personally? I occasionally can write that kind of stuff.

You can still write routines in assembly, you cant write it inline.

You can also use intrinsics if you don't want to write your entire routine in assembly.

You are supposed to use special MASM directives to generate function tables for SEH.

There are few reasons to use assembly, and even fewer to use inline assembly

Using CPUID is one, using very specific vector instructions another (but you can do most of this using intrinsics) and it's better if they get their own .s file

inline assembly e.g. intermixed with C/C++ code is not supported. You can still have separate files that are ASM only.

It's more hassle, but still possible to use.