7 ms·

> Also, thank you for using Intel x86 syntax instead of AT&T. Thank you for helping to validate that decision; this is the kind of feedback we needed. (And no

> Also, thank you for using Intel x86 syntax instead of AT&T. Thank you for helping to validate that decision; this is the kind of feedback we needed. (And note that you can still choose to use AT&T syntax, it just isn't the default.)

binarycrusader 6y ago
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 ;)
exmadscientist 6y ago
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 :)
- JoshTriplett 6y ago
  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.
jdright 6y ago
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).
mzs 6y ago
I prefer AT&T, thank you for the option.
userbinator 6y ago
Old article but still valid: http://x86asm.net/articles/what-i-dislike-about-gas/ http://x86asm.net/articles/what-i-dislike-about-gas/
burfog 6y ago
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)

binarycrusader 6y ago

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 ;)

exmadscientist 6y ago

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 :)

JoshTriplett 6y ago
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.

jdright 6y ago

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).

mzs 6y ago

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

userbinator 6y ago

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

burfog 6y ago

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)