5 ms·

This. The AT&T syntax for x86 thing is a huge mistake. All the official docs are Intel syntax. Intel syntax is easier to read and write. Half the gotchas in t

This. The AT&T syntax for x86 thing is a huge mistake. All the official docs are Intel syntax. Intel syntax is easier to read and write. Half the gotchas in this article are problems that don't exist in Intel syntax, like the instruction suffixes. The instruction suffixes get even weirder when you get to the sign extending instructions. I wrote an article about this here: http://blog.reverberate.org/2009/07/giving-up-on-at-style-assembler-syntax.html http://blog.reverberate.org/2009/07/giving-up-on-at-style-as...

pjmlp 10y ago
Additionally Intel syntax Macro Assemblers offer higher level constructs providing almost C like experience while using machine opcodes.
Annatar 10y ago
The AT&T syntax for x86 thing is a huge mistake. For someone who grew up on normal processors (MC68000 and UltraSPARC) AT&T syntax is the best thing since sliced bread: it's perfectly logical to move something to somewhere, instead of "move to somewhere something".
- userbinator 10y ago
  I haven't done any 68K Asm and barely glanced at SPARC, but how does src, dst interact with noncommutative operations like subtraction and comparison? E.g. with x86 Intel syntax, cmp eax, 5 ; eax - 5 jg morethan5 ; eax > 5 ? then jump. sub eax, ecx ; eax = eax - ecx This is one of the most confusing things about AT&T x86 --- the comparisons and subtractions have their operands reversed, and you have to identify and manually reverse them to understand the code correctly. With Intel syntax, the operands to a subtraction appear in the usual arithmetic order. Or do those processors' syntax keep the order but instead replace the subtrahend with the result?? sub A, B ; B = A - B ??
  - haberman 10y ago
    Exactly this. The instruction set is designed around Intel syntax. When you flip operands around because you prefer a different ordering, it messes up things like jg/ja/jl/jb/etc. And it's all arbitrary anyway. Some people might prefer a [src, dest] ordering, but it's not inherently any more natural than [dest, src]. Look at variable assignments: "x = y" in almost any programming language will assign y to x.
    - Annatar 10y ago
      Yeah but in most assemblers you're not setting, but either loading or moving values into something, or from somewhere. Because of that, one never has to think in terms of x = y.
      - haberman 10y ago
        What is the difference between "setting" and "loading or moving"? I can't see any semantic difference between "eax = edi" and "mov eax, edi".
        Annatar 10y ago
        None, but in assembler one simply doesn't think in terms of x = y, it's not necessary.
  - Annatar 10y ago
    This is one of the most confusing things about AT&T x86 --- the comparisons and subtractions have their operands reversed, That is confusing as all hell to me: if I compare x to 5, and 5 to x, it's still the same comparison, so what difference does it make? Anyway, on Motorola 68000 it would look like so, assuming data was in data register 0 (there are eight general purpose data registers, and eight general purpose address registers): cmp.l #5, d0 ; d0 is unchanged by the comparison bgt MoreThanFive ; ; substract the value of d1 from d0, and store the result ; in d0. ; sub.l d1, d0 however, we don't usually branch if greater or lower; we simply compare whether a register is equal to some value: cmp.l #5, d0 bne NotFive
- dkersten 10y ago
  Thats only part of the syntax differences between AT&T and Intel. Also, "move destination, source(s)" is consistent regardless how many sources there are (although I agree with you that "source -> destination" is more intuitive for us left-to-right people).
wolfgke 10y ago
I prefer Intel syntax and admit that you have a good argument in your article why the AT&T syntax might be problematic, but for newer extensions (SSE etc.) the instruction naming in Intel syntax actually converged towards AT&T syntax: Just to give an example from SSE2 (from http://softpixel.com/~cwright/programming/simd/sse2.php http://softpixel.com/~cwright/programming/simd/sse2.php): paddb - Adds 16 8bit integers. paddw - Adds 8 16bit integers. paddd - Adds 4 32bit integers. paddq - Adds 2 64bit integers.
- userbinator 10y ago
  That's not really "AT&T syntax", since the suffixes here are denoting how the MMX/XMM register is being split up and not the whole operand size. Those instructions can still be used with either the 64-bit MMX or 128-bit XMM registers: paddb mm0, mm1 paddb xmm0, xmm1 If it was really more like "AT&T" style (I don't know how GNU really does this, so I'm guessing), it would be more like paddqb for MMX and paddob for SSE.
  - wolfgke 10y ago
    I accept the argument that the suffixes mean something a little different in these SSE2 instructions than in the "classical" x86 instructions. But I think it should be clear where these suffixes come from (thus there is some convergence of the Intel syntax for new instruction towards the AT&T syntax). And indeed the instructions paddb, paddw, paddd, paddq are the same on Intel and AT&T syntax. Look at > https://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf https://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf First convince yourself (for example by looking at page 26-39) that in the individual tables the column "Solaris Mnemonic" stands for the AT&T syntax and the column "Intel/AMD Mnemonic" stands for the Intel syntax. Now look at page 48. Surprise: It is paddb, paddw, paddd, paddq both in Intel and AT&T syntax.

pjmlp 10y ago

Additionally Intel syntax Macro Assemblers offer higher level constructs providing almost C like experience while using machine opcodes.

Annatar 10y ago

The AT&T syntax for x86 thing is a huge mistake. For someone who grew up on normal processors (MC68000 and UltraSPARC) AT&T syntax is the best thing since sliced bread: it's perfectly logical to move something to somewhere, instead of "move to somewhere something".

userbinator 10y ago
I haven't done any 68K Asm and barely glanced at SPARC, but how does src, dst interact with noncommutative operations like subtraction and comparison? E.g. with x86 Intel syntax, cmp eax, 5 ; eax - 5 jg morethan5 ; eax > 5 ? then jump. sub eax, ecx ; eax = eax - ecx This is one of the most confusing things about AT&T x86 --- the comparisons and subtractions have their operands reversed, and you have to identify and manually reverse them to understand the code correctly. With Intel syntax, the operands to a subtraction appear in the usual arithmetic order. Or do those processors' syntax keep the order but instead replace the subtrahend with the result?? sub A, B ; B = A - B ??
- haberman 10y ago
  Exactly this. The instruction set is designed around Intel syntax. When you flip operands around because you prefer a different ordering, it messes up things like jg/ja/jl/jb/etc. And it's all arbitrary anyway. Some people might prefer a [src, dest] ordering, but it's not inherently any more natural than [dest, src]. Look at variable assignments: "x = y" in almost any programming language will assign y to x.
  - Annatar 10y ago
    Yeah but in most assemblers you're not setting, but either loading or moving values into something, or from somewhere. Because of that, one never has to think in terms of x = y.
    - haberman 10y ago
      What is the difference between "setting" and "loading or moving"? I can't see any semantic difference between "eax = edi" and "mov eax, edi".
      - Annatar 10y ago
        None, but in assembler one simply doesn't think in terms of x = y, it's not necessary.
- Annatar 10y ago
  This is one of the most confusing things about AT&T x86 --- the comparisons and subtractions have their operands reversed, That is confusing as all hell to me: if I compare x to 5, and 5 to x, it's still the same comparison, so what difference does it make? Anyway, on Motorola 68000 it would look like so, assuming data was in data register 0 (there are eight general purpose data registers, and eight general purpose address registers): cmp.l #5, d0 ; d0 is unchanged by the comparison bgt MoreThanFive ; ; substract the value of d1 from d0, and store the result ; in d0. ; sub.l d1, d0 however, we don't usually branch if greater or lower; we simply compare whether a register is equal to some value: cmp.l #5, d0 bne NotFive
dkersten 10y ago
Thats only part of the syntax differences between AT&T and Intel. Also, "move destination, source(s)" is consistent regardless how many sources there are (although I agree with you that "source -> destination" is more intuitive for us left-to-right people).

wolfgke 10y ago

I prefer Intel syntax and admit that you have a good argument in your article why the AT&T syntax might be problematic, but for newer extensions (SSE etc.) the instruction naming in Intel syntax actually converged towards AT&T syntax: Just to give an example from SSE2 (from http://softpixel.com/~cwright/programming/simd/sse2.php http://softpixel.com/~cwright/programming/simd/sse2.php): paddb - Adds 16 8bit integers. paddw - Adds 8 16bit integers. paddd - Adds 4 32bit integers. paddq - Adds 2 64bit integers.

userbinator 10y ago
That's not really "AT&T syntax", since the suffixes here are denoting how the MMX/XMM register is being split up and not the whole operand size. Those instructions can still be used with either the 64-bit MMX or 128-bit XMM registers: paddb mm0, mm1 paddb xmm0, xmm1 If it was really more like "AT&T" style (I don't know how GNU really does this, so I'm guessing), it would be more like paddqb for MMX and paddob for SSE.
- wolfgke 10y ago
  I accept the argument that the suffixes mean something a little different in these SSE2 instructions than in the "classical" x86 instructions. But I think it should be clear where these suffixes come from (thus there is some convergence of the Intel syntax for new instruction towards the AT&T syntax). And indeed the instructions paddb, paddw, paddd, paddq are the same on Intel and AT&T syntax. Look at > https://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf https://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf First convince yourself (for example by looking at page 26-39) that in the individual tables the column "Solaris Mnemonic" stands for the AT&T syntax and the column "Intel/AMD Mnemonic" stands for the Intel syntax. Now look at page 48. Surprise: It is paddb, paddw, paddd, paddq both in Intel and AT&T syntax.