Having used gcc inline assembly a decent amount, I'd personally say it's not worth it. Almost every example and existing code out there is AT&T, so you're creat

Having used gcc inline assembly a decent amount, I'd personally say it's not worth it. Almost every example and existing code out there is AT&T, so you're creating an extra step for yourself in converting to intel, and IMO AT&T syntax isn't that bad - it's not great by any means, but having started with intel syntax I didn't find AT&T that hard to pick up (Besides the source/dest thing, which is really annoying). I think the big thing to note is that your inline assembly should really be as short as possible - larger sections are going to have more and more inputs/outputs/constraints, and those will prevent gcc from doing lots of optimizations with it since it doesn't understand and can't modify the assembly (I could go into more details on this if you'd like, if you're not already aware of this). For most use-cases, your inline assembly should just be exposing things you can't do in C (Like exotic or CPU-specific instructions) for use in your C code. So at that point, most of your inline assembly just becomes one or two instructions long, and the syntax doesn't really matter as much. For larger blocks of assembly, you should just compile it separately (At which point you could use intel syntax if you like).