←back to thread

Rules to avoid common extended inline assembly mistakes

(nullprogram.com)
73 points ingve | 4 comments | 20 Dec 24 20:03 UTC | HN request time: 0.001s | source
Show context
wyldfire ◴[21 Dec 24 03:41 UTC] No.42477388[source]▶
> 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.

replies(2): >>42479044 #>>42481487 #
1. bjackman ◴[21 Dec 24 11:28 UTC] No.42479044[source]▶
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!

replies(2): >>42479912 #>>42479933 #
2. ◴[21 Dec 24 14:32 UTC] No.42479912[source]▶
3. ryandrake ◴[21 Dec 24 14:36 UTC] No.42479933[source]▶
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

replies(1): >>42480053 #
4. wyldfire ◴[21 Dec 24 15:00 UTC] No.42480053[source]▶
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/