Hacker News Reader

Comment by SassyBird | Hacker News Reader

It seems that MSVC supports inline assembly only on 32-bit x86. For amd64 and ARM they moved entirely to intrinsics.

The more I've written code close to metal (mostly SIMD for signal processing), the more I've grown to prefer either intrinsics or separate translation unit for assembly.

If you want your code to intertwine with what the C compiler does, intrinsics are great.

If you don't, .s is great.

Exactly, this is the right approach.

And the only way to use new instructions is to make them slow or to wait for a compiler update.

Yes, and the set of intrinsics supported by MSVC is really lacking. On x64, this left no way to force a conditional move to bypass a poorly predictable branch, nor was there a way to access carry-extended operations until recently. On ARM64, it doesn't have complete coverage of scalar intrinsics for operations like RBIT (reverse bit order).

Yes, Assembly programming concatenanting strings, is horrible.

Intrisics give the best of both worlds, without dealing with string based content.

Actually ESPOL/NEWP from 1961 was one of the very first system programming languages with two key inovations, intrisics and unsafe code blocks.

I’m not a fan of concatenating strings either. I was thinking about the MSVC/Pascal-style inline assembly here, which isn’t based on strings.

Correct me if I’m wrong, but I don’t think that you can guarantee a routine is constant-time by using intrinsics. You need asm for that. Asm that won’t be changed by the compiler. So you need to write an external asm file for that now, which is fair enough, but I just wouldn’t present intrinsics as all-around superior.

Yes, if you want full control, only external Assemblers will do the trick.

Reply on news.ycombinator.com