5 ms·

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 straightforwar

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.

monadic2 6y ago
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.
- asveikau 6y ago
  > 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.
  - saagarjha 6y ago
    > However Microsoft has de-emphasized inline assembly and doesn't allow it on amd64 or ARM. That's just sad :(
    - monadic2 6y ago
      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.
      - mlyle 6y ago
        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).
    - asveikau 6y ago
      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).
      - monocasa 6y ago
        I've used it with SH4 on Windows CE.

monadic2 6y ago

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.

asveikau 6y ago
> 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.
- saagarjha 6y ago
  > However Microsoft has de-emphasized inline assembly and doesn't allow it on amd64 or ARM. That's just sad :(
  - monadic2 6y ago
    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.
    - mlyle 6y ago
      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).
  - asveikau 6y ago
    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).
    - monocasa 6y ago
      I've used it with SH4 on Windows CE.