4 ms·

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 slic

by 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
  - deleted 10y ago
    [deleted]
  - vram22 10y ago
    >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? I haven't done assembly code for a while, and was not an expert at it earlier, so guessing, but: it may be because of what flags in the flags register (if there is one nowadays) get set - they could be different for the two versions of your comparison.
    - Annatar 10y ago
      Yes, there is a status register, every processor must have one (or else the processor couldn't function). Doesn't matter whether you compare 5 to a register (or memory location, depending on the processor), or memory / register to 5, the same bit(s) will still be set in the status register.
      - vram22 10y ago
        >Doesn't matter whether you compare 5 to a register (or memory location, depending on the processor), or memory / register to 5, the same bit(s) will still be set in the status register. Are you sure? That was my whole point - that it may not be that way. As I said, it's been a while, but it seems to me that the bits that get set in the flags/status register, on comparing A to B, should be, in some sense at least, the opposite (maybe not for all the bits) of what would get set on comparing B to A; because I thought it would be done by subtracting A from B or B from A, and then setting (some of) those flag bits based on which was greater or equal. If that is so, comparing A to B will not have the same result in the register as comparing B to A. And the reason why I think so, is that there are assembly instuctions like JGE (Jump if Greater or Equal), JE (Jump if Equal), JNE (Jump if Not Equal), etc. - the meaning of those instructions would get changed and so would the resulting action (jump or not jump) based on the looking at the flags set on comparing A to B vs. B to A.
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).

by Annatar 10y ago

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
- deleted 10y ago
  [deleted]
- vram22 10y ago
  >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? I haven't done assembly code for a while, and was not an expert at it earlier, so guessing, but: it may be because of what flags in the flags register (if there is one nowadays) get set - they could be different for the two versions of your comparison.
  - Annatar 10y ago
    Yes, there is a status register, every processor must have one (or else the processor couldn't function). Doesn't matter whether you compare 5 to a register (or memory location, depending on the processor), or memory / register to 5, the same bit(s) will still be set in the status register.
    - vram22 10y ago
      >Doesn't matter whether you compare 5 to a register (or memory location, depending on the processor), or memory / register to 5, the same bit(s) will still be set in the status register. Are you sure? That was my whole point - that it may not be that way. As I said, it's been a while, but it seems to me that the bits that get set in the flags/status register, on comparing A to B, should be, in some sense at least, the opposite (maybe not for all the bits) of what would get set on comparing B to A; because I thought it would be done by subtracting A from B or B from A, and then setting (some of) those flag bits based on which was greater or equal. If that is so, comparing A to B will not have the same result in the register as comparing B to A. And the reason why I think so, is that there are assembly instuctions like JGE (Jump if Greater or Equal), JE (Jump if Equal), JNE (Jump if Not Equal), etc. - the meaning of those instructions would get changed and so would the resulting action (jump or not jump) based on the looking at the flags set on comparing A to B vs. B to A.

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