3 ms·

> Because it’s so treacherous, the first rule is to avoid it if at all possible. Modern compilers are loaded with intrinsics and built-ins that replace nearly a

> Because it’s so treacherous, the first rule is to avoid it if at all possible. Modern compilers are loaded with intrinsics and built-ins that replace nearly all the old inline assembly use cases. If you take away anything from this article, it should be at least this. Intrinsics/builtins should be your first approach. Only use inline assembly if you can't express what you need using intrinsics.

bjackman 2y ago
I have a fun exception to this! When writing BPF programs, sometimes it's tricky to get the compiler to generate code that passes the verifier. This can lead you down a path of writing bizarre C in order to try and produce the right order of checks and register allocations. So, use inline asm! It's not portable any more... But it's a BPF program! There's nothing to port it to. It's less readable... Wait no, it's _more_ readable because BPF asm has good syntax and you can avoid the bizarre C backflips to satisfy the verifier. It's unsafe... Wait no, it's checked for safety at load time!
- deleted 2y ago
  [deleted]
- ryandrake 2y ago
  For the curious, BPF in this case might mean Berkeley Packet Filter[1]. Not sure. Kind of an obscure acronym but Google search seems to have a consensus. 1: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
  - wyldfire 2y ago
    It does. These days, it's probably eBPF and a popular target is the linux kernel [1]. You can write C hooks for tracing and profiling, etc. - with inline asm! [1] https://docs.kernel.org/bpf/ https://docs.kernel.org/bpf/
AlotOfReading 2y ago
It's surprisingly easy to find things the language and intrinsics don't allow you to express when you look closely enough at what the compiler is generating. I recently wrote code that uses inline assembly not to generate instructions, but to confuse the optimizer just enough that it stops breaking the correct instructions it's already generating.

bjackman 2y ago

I have a fun exception to this! When writing BPF programs, sometimes it's tricky to get the compiler to generate code that passes the verifier. This can lead you down a path of writing bizarre C in order to try and produce the right order of checks and register allocations. So, use inline asm! It's not portable any more... But it's a BPF program! There's nothing to port it to. It's less readable... Wait no, it's _more_ readable because BPF asm has good syntax and you can avoid the bizarre C backflips to satisfy the verifier. It's unsafe... Wait no, it's checked for safety at load time!

deleted 2y ago
[deleted]
ryandrake 2y ago
For the curious, BPF in this case might mean Berkeley Packet Filter[1]. Not sure. Kind of an obscure acronym but Google search seems to have a consensus. 1: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
- wyldfire 2y ago
  It does. These days, it's probably eBPF and a popular target is the linux kernel [1]. You can write C hooks for tracing and profiling, etc. - with inline asm! [1] https://docs.kernel.org/bpf/ https://docs.kernel.org/bpf/

AlotOfReading 2y ago

It's surprisingly easy to find things the language and intrinsics don't allow you to express when you look closely enough at what the compiler is generating. I recently wrote code that uses inline assembly not to generate instructions, but to confuse the optimizer just enough that it stops breaking the correct instructions it's already generating.