3 ms·

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

by SassyBird 2y ago

vnorilo 2y ago
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.
- pjmlp 2y ago
  Exactly, this is the right approach.
- immibis 2y ago
  And the only way to use new instructions is to make them slow or to wait for a compiler update.
pjmlp 2y ago
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.
- SassyBird 2y ago
  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.
  - pjmlp 2y ago
    Yes, if you want full control, only external Assemblers will do the trick.
ack_complete 2y ago
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).

3 ms·

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

by SassyBird 2y ago

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

vnorilo 2y ago
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.
- pjmlp 2y ago
  Exactly, this is the right approach.
- immibis 2y ago
  And the only way to use new instructions is to make them slow or to wait for a compiler update.
pjmlp 2y ago
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.
- SassyBird 2y ago
  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.
  - pjmlp 2y ago
    Yes, if you want full control, only external Assemblers will do the trick.
ack_complete 2y ago
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).