Yes, thank you for the Intel syntax. It is by far the most frequent syntax you'll find anywhere somewhat recent (1990+) and it is by far the most straightforward to learn by being clean. I did learn both in the 90s, but I've always struggled with AT&T symbols and different offerings which to me was hard to switch to when learning from different material sources.

FWIW I mostly see AT&T when compiling against C codebases to a) avoid requiring a secondary assembler & wanting to support legacy binutils and b) because inline C is AT&T in practice, at least outside of windows (no clue what the c ecosystem is like there). However, most resources exploring “assembly” do so in a context where it makes sense to use intel syntax & work with a “dedicated” assembler.

That said, this is a good decision because C compilers seem to be the major holdouts at this point—binutils has had .intel_syntax for a long time now, it’s just not supported inline.

> at least outside of windows (no clue what the c ecosystem is like there).

Microsoft's assembler uses Intel syntax, and their inline assembly also uses Intel syntax.

Their inline assembly is much less explicit about inputs, outputs, and clobbers, and "just" has you mix C symbols and labels with assembly instructions, which I imagine is a pain to get right.

However Microsoft has de-emphasized inline assembly and doesn't allow it on amd64 or ARM. For things that need specific instructions you need to either use intrinsics or put assembly in a different object file.

> However Microsoft has de-emphasized inline assembly and doesn't allow it on amd64 or ARM.

That's just sad :(

I suspect if they had a situation like GCC where the programmer had to annotate the side effects of every assembly snippet, it would have been easier for them to add it elsewhere.

But the way they had it, they presented a seamless blend of assembly instructions and any C identifier, in or out, and I guess the compiler would need to parse out any side effects and cope with them. My guess is they looked at porting all that to ia64 [which they supported until Server 2008 R2], amd64 and ARM and balked.

No idea if they ever had it on some of the old architectures they supported in NT4 days or on CE (alpha, mips, ppc).

I've used it with SH4 on Windows CE.

I gotta say, I’ve written thousands of lines of assembler and can count the times that inline assembly was clearly useful on one hand. The clear benefits seem to be readability and concentration of documentation.

I've had a whole bunch of projects that have needed 2 to 40 instructions of assembly-- often preferable for the the assembly to be inlined to improve performance and surrounded by closely-related C code on both sides.

Examples: An abort call on an embedded system that needs to disable interrupts to prevent task switching after the abort. One instruction.

An implementation of _start for embedded that can do everything in C except setting a couple processor flags. Two instructions.

Running (with a lock) event callbacks in an embedded system on their own stack, so that not all tasks need to have their stack big enough to handle the stuff the callbacks might do; 5 instructions that are far better inlined than having another call and indirection. (In addition to keeping doc/code together).

Yes, this is great, but I have to disagree on the Intel x86 syntax assertion by the original poster. Perhaps it's because of the era I grew up in and how I first learned machine language and then assembly language, but I've always preferred AT&T syntax. Regardless thanks for supporting the saner syntax even if it's not by default ;)

If you're ever in doubt on which syntax to implement first or make default, just look at the processor manual (TRM). Match it, and you'll have an ironclad defense :)

That was one of our primary justifications. The tradeoff was between that and what's currently widely used with GCC and clang; the latter (along with people porting from what's now called llvm_asm!) motivated us adding the att_syntax option.

Old article but still valid: http://x86asm.net/articles/what-i-dislike-about-gas/

I prefer AT&T, thank you for the option.

For ARM, can we have the "." separators? They are standard for Aarch64 anyway, and they make the 32-bit code far easier to read. Like so:

add.s.ne

ldm.ia.cc

(in both orders, for those cases with two suffixes)