No one should use the AT&T syntax (2021) • Hacker News Board

Re: No one should use the AT&T syntax (2021)

#61

Post by gergo_barany » Sun, Jun 09, 2024, 7:31 PM UTC

torstenvl wrote: post #28

> mov eax, ebx ; (1) load one dword from the EBX register and store it in the EAX register This is a mov instruction, not a ld instruction. There is no loading going on. The value in EBX is already loaded. Otherwise it wouldn't be in a register. It's hard for me to take someone seriously who doesn't understand the difference between a load and a move but feels as if they have the right to an opinion about assembly.

Note that LEA (load effective address) doesn't load from memory either. Intel also uses "load" in the descriptions of register-to-register moves: https://www.felixcloutier.com/x86/mov-2 . Although confusingly, here "load register X" seems to mean "store to register X" (and again, not a memory store). Anyway, the word "load" doesn't imply "from memory" the way you suggest.

Re: No one should use the AT&T syntax (2021)

#62

Post by clausecker » Sun, Jun 09, 2024, 7:31 PM UTC

aap_ wrote: post #58

I much prefer AT&T to intel syntax. i concede that cmp has the operand order swapped but otherwise i have to think less about it. Of course it's a matter of taste, but to me at least AT&T just feels nicer.

I like it, too. If you understand how it came to be (https://stackoverflow.com/a/42250270/417501), it's quite sensible. Also saves me from writing DWORD PTR all over the place.

Re: No one should use the AT&T syntax (2021)

#63

Post by pclmulqdq » Sun, Jun 09, 2024, 7:33 PM UTC

AshamedCaptain wrote: post #55

pclmulqdq wrote: post #25

Earlier quoted context omitted.

If you write for any CPU other than an x86, the Intel assembler syntax matches the syntax order you would get. It also sort of lines up with C and C++ syntax of putting the result on the left. I might be biased as an Intel-syntax-loving assembly-writing heathen.

> If you write for any CPU other than an x86 The at&t syntax didn't appear in a vacuum. There are several architectures, e.g. popularly m68k, which use this order.

All of them but x86 are obsolete. I don't know anyone who has written 68000 assembly for professional use in the last 20 years.

Re: No one should use the AT&T syntax (2021)

#64

Post by OnionBlender » Sun, Jun 09, 2024, 7:36 PM UTC

Years ago I emailed the creator of Exapunks (a puzzle game where you write assembly in a made up instruction set) and asked why he used AT&T syntax instead of Intel syntax. He said it seemed more intuitive for English speakers.

> This is usually only brought up by people who have prior assembly programming experience, which makes me think we made the right choice.

Re: No one should use the AT&T syntax (2021)

#65

Post by pclmulqdq » Sun, Jun 09, 2024, 7:39 PM UTC

ralferoo wrote: post #49

ketzu wrote: post #17

Earlier quoted context omitted.

> Operand order in AT&T is really dumb I always found AT&T order much more intuitive to read. The "what am I doing" and then "where will it go" felt natural to me. But I didn't do much assembler, so my opinion doesn't matter :)

I first learned assembler on Z80, and so the Intel syntax should be more natural to me, but I migrated from that to 68000 which uses destination-last syntax, and never really had any problems with it even though I'd been using Z80 for a few years by then. About a year after learning 68000, I started coding 8086 assembler and felt that Intel syntax was backwards, even though it's the same order as the Z80 I started on…

If Intel allowed you to do "MOV RAX, [address]" (inferring the QWORD PTR part from the "RAX"), most peoples' primary aesthetic objection to the syntax would be gone.

Re: No one should use the AT&T syntax (2021)

#66

Post by kragen » Sun, Jun 09, 2024, 7:44 PM UTC

gergo_barany wrote: post #30

kstenerud wrote: post #14

> Putting the destination operand first emphasizes the site of mutation. This doesn't make any more convincing an argument than the "linguistic" and "consistency" arguments he shot down earlier. Why should putting the mutated argument first emphasize it any more than putting it second? If you order things the same way every time, people will implicitly know which one is the mutated argument because that's how the lan…

I'd agree that there is no strong inherent benefit to either ordering, except that it would be good not to needlessly violate expectations about mathematical operations. AT&T also permutes the order of operands of comparisons, which is just bizarre: https://gcc.godbolt.org/z/h6EcP5Yv9 "Compare A and B and do X if result is 'less than'" should never mean "do X if B is less than A". Anyway, the most important considera…

the comparison operand ordering problem is a legitimate problem that i keep having even after having written thousands of lines of assembly in at&t syntax. i hope it goes away after i get to tens of thousands...

Re: No one should use the AT&T syntax (2021)

#67

Post by tmtvl » Sun, Jun 09, 2024, 7:54 PM UTC

kazinator wrote: post #20

OK, so renaming a file should be: $ mv new-name.txt old-name.txt I defer to the blogger's superior UX expertise!

Eh, there's examples of every permutation:

  ;; Lisp
  (setf a (xor b c))
  ;; Kanren
  ;; Unification instead of mutation.
  ;; Therefore these are equivalent:
  (== a (xor b c))
  (== (xor b c) a)
  # Contrived untested Raku example
  $b ^^ $c ==> my $a;
  % Amberjack
  b xor c -> a
  // Java
  var a = b ^ c;

Re: No one should use the AT&T syntax (2021)

#68

Post by amluto » Sun, Jun 09, 2024, 7:57 PM UTC

jcranmer wrote: post #54

amluto wrote: post #39

I think there are two legitimate reasons to use Intel syntax: 1. It matches the manual. AMD and Intel’s manuals agree about operand order, and IMO there is no justification whatsoever for an assembly syntax to fail to match the documentation. This is especially true for 3-address instructions and for two-input instructions like CMP. All these arguments about mathematical notation or linguistics are nonsense in my boo…

Don't forget the weirdness of AVX-512 masks in AT&T syntax!

I sincerely hope I never have to touch code like that.

I have messed with code to save and restore AVX-512 registers, and this is about the only thing I like about AT&T syntax: there’s a uniform way to specify the instruction size that works when the instruction has no operands. I’m looking at you, XSAVE, XRSTOR, SYSRET, etc. The manual has no useful syntax to offer here.

Re: No one should use the AT&T syntax (2021)

#69

Post by spcharc » Sun, Jun 09, 2024, 8:02 PM UTC

I love AT&T syntax.

I originally started with Intel syntax when learning assembly since it was just in my textbook. I sometimes ran into weird syntax issues I didn't yet understand.

For example, why "mov eax, [ebx + 2 * ecx + 4]" is allowed, but not "mov eax, [ebx + ecx + edx]" (1)? Or maybe "mov eax, [ebx + 3 * ecx]" (2)? Or maybe "mov eax, [2 * ebx + 4 * ecx]" (3)?

As long as it is a math expression it should work right? Why did the compiler keeps telling me the expression is invalid?

Later when I learned about AT&T syntax, everything started to make sense. The syntax ensures you cannot construct (1) and (3), and when trying to use (2) it explicitly tells you it expects 1, 2, 4, or 8 but got 3.

I started to use AT&T syntax since then.

In my opinion, there is one most confusing part about AT&T syntax, which is the condition based instructions. I guess the original author of the article did not do much programming with AT&T syntax so they did not notice.

  cmpl %eax, %ebx
  jae label

Now tell me if eax is bigger, should you jump to label?

Instead, with Intel syntax it is pretty straight forward. The "jae ..." following "cmp ebx, eax" translates to "if (ebx >= eax) goto ..."

(BTW, the cat or whatever following your mouse pointer is super annoying)

Re: No one should use the AT&T syntax (2021)

#70

Post by ack_complete » Sun, Jun 09, 2024, 8:05 PM UTC

amluto wrote: post #39

I think there are two legitimate reasons to use Intel syntax: 1. It matches the manual. AMD and Intel’s manuals agree about operand order, and IMO there is no justification whatsoever for an assembly syntax to fail to match the documentation. This is especially true for 3-address instructions and for two-input instructions like CMP. All these arguments about mathematical notation or linguistics are nonsense in my boo…

AT&T syntax for x86-64 introduces tons of nonstandard instruction names that you will never find in the official manuals. WTF are: movabs, cqto, filds, and ljmp?

I also don't understand why x86 syntax has to be mutilated when special syntax is supported for other architectures. It's somehow OK for ARM64 to have [x1, w9, sxtw #2] or [x3, #32]! and 68K to have (%a2,%d1.l8), but x86-64 can't have [%rcx + %rdx4].

Reading x86-64 disassembly in AT&T syntax is just painful.