←back to thread

Rules to avoid common extended inline assembly mistakes

(nullprogram.com)
73 points ingve | 1 comments | 20 Dec 24 20:03 UTC | HN request time: 0s | 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. AlotOfReading ◴[21 Dec 24 19:02 UTC] No.42481487[source]▶
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.