On Thu, Jun 27, 2019 at 05:46:00AM -0600, Jan Beulich wrote: > While maybe not explicitly applicable here, the intrinsics aren't > (afaict) providing full flexibility. In particular (just as example) > I haven't found a way to use embedded broadcast with the > intrinsics, but I can easily do so with asm(). > > Furthermore there are other reasons to use asm() - things like > the Linux kernel are full of it for a reason.
Some of it for a (good) reason. Yes. > And once one has > to use asm(), the resulting code typically is easier to follow if > one doesn't further intermix it with uses of builtins. If you have to write more than a few lines of assembler, you are usually *much* better off just writing it in an assembler source file (a .s). > And finally, if asm() was indeed meant to be deprecated, how > come it pretty recently got extended to allow for "inline"? That was just a simple extension for a very specific purpose. This does not mean you should use inline assembler if there are better alternatives. I'm not sure Linux using such extremely huge inline assembler statements is a good idea at all, or if there are better ways to do what they want (not that I see any fwiw); but they already did, and this takes the pain away a bit for them, so why not. You should not use inline assembler when there are better way of expressing what you want. Like with builtins, for example. Inline assembler is hard to write correctly, and hard to *keep* correct. It is mixing abstractions (that is its *purpose*), which of course makes it a royal pain to deal with, esp. if overused. Segher
