Hacker News Reader

Comment by jclulow | Hacker News Reader

I wonder what makes AT&T assembly syntax "objectively crap".

You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax:

  Intel: mov eax, 5
  AT&T: movl $5, %eax

In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved.

Intel's syntax for memory access seems more natural. If I don't want to add `ebx` to the address, I can leave it out; I can't in AT&T; I have to have this seemingly random comma. Plus, what's with the format?

  Intel: mov eax, [ds:eax*4+16]
  AT&T: movl ds:16(,%eax,4)

Interestingly, in the language you actually wrote that complaint in:

> you assign 5 to eax

AT&T speaks English, basically. We move A to B. Destination goes last.

Both seem sane enough. And in fact both get really balled up when you have three and four-argument instructions.

I'll grant that, but it's a programming language, so I kind of expect it to follow the order assignment does when I write in C++, C#, etc.

AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing.

[1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called some variant of "MOV". Yeah, yeah, we know.

What.

When did `mov` get 96 different instructions?

I think it's just a bit of hyperbole. I don't know enough of this to know whether http://c9x.me/x86/html/file_module_x86_id_176.html is complete, but it gives you a sense of it all. (also https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf if you haven't seen it)

Huh, interesting.

Apparently there are 35 rows in the table at http://www.felixcloutier.com/x86/MOV.html (according to Chrome and `$0.childElementCount`). I only discovered gcc.godbolt.org links to documentation via context menu just the other day!

Regarding the PDF... ouch. Wonder if any executable obfuscators have tried that approach :P (and I also wonder what sort of overhead it has.)

> I kind of expect it to follow the order assignment does when I write in C++, C#, etc.

There is no special precedence that should be applied to C. Similarity to C only imparts benefits to those that are fimilar with C-like languages or variants that follow that structure. That ends up being a lot of people because of how popular C and variants have been, but that's doesn't inherently make it better.

It's sort of a pet peeve of mine when people point out differences from C as problems without any objective facts to back up whether it actually is more or less useful in some aspects. If we never stood up to that type of thinking, we'd all by much poorer in the programming language department.

This does raise the question: which languages other than AT&T assembly put the value first?

AT&T syntax puts the operator first, not the value. AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Many kinds of S expressions result in similar code. That would mean Lisp derivatives.

> AT&T syntax puts the operator first, not the value.

If "operator" has any meaning in assembly language, it would have to refer to the opcode. Both variants have the opcode (mov/movl) first.

> AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Both "move 5 into EAX" and "move into EAX the value 5" are imperatives. Neither of them has a subject, or more precisely, the subject is omitted (https://en.wikipedia.org/wiki/Imperative_mood). In both of these, 5 is an object. "into EAX" is an adverbial phrase or something.

It's true that one sounds more alien than the other when forcibly translated to English. Then again, assembly language is not English, so that's neither here nor there.

Sloppy of me, but I meant value before the variable/register.

Right, but the mnemonic reads better in AT&T then "move 5 to register eax" and Intel seems backwards.

It's what you get used to. I'm used to x86 being "dst,src". It never bothered me that on the Motorola 68000 it went "src,dst" as, it was what it was. Intel defined it one way, Motorola another way [1].

My gripe with AT&T style (and it's called AT&T because K&R wrote their assembler that way) is that it uses sigils to mark registers (something I've never seen any other assembler do) and specifically broke with the manufacturer's mnemonics. Yes, I can see why they did it that way (a consistent format for assembly across multiple architectures) but I don't necessarily agree with it (Go's assembler has gone father by not even bothering with the register names the manufacturer uses).

Almost forgot---another annoying aspect of AT&T is the use of "$" to designate an immediate value. Every assembler I used (prior to my exposure to Unix) used "#" for immediate value, and "$" for hexadecimal. But noooo, AT&T had to use "$" for immediate, and "0x" to designate hexadecimal and thus, I hit a brick wall each time I read code in AT&T format.

[1] Also interesting to note---Intel is little endian, Motorola is bigendian.

I learned on Intel and that's the only I can use. Just pointing out that reading the expression makes more sense in AT&T style so might be why they did it that way.

And always wondered why the need for % in AT&T for registers. It seems like there would no ambiguity based on instruction.

Why would you expect assignment order to be similar? Nothing else about c syntax is shared.

If anything, at&t follows English: move literal 5 into register eax.

Makes you wonder why not write it as e.g. "eax mov 5" or even "eax = 5".

I've seen assembly languages that do separate target and source operands with an = sign. So you would write that something like:

    mov eax = 5

and use a similar style for other things, like:

    add eax = ebx, ecx

This is very nice and clear. But it only really works for three-address assembly languages, i.e., where the target register may be different from the sources. In classical x86, the target of an add is identical to one of the operands. So you would need something like

    add eax += ebx

    add eax = eax, ebx

where you must duplicate a register. Presumably when these assembly languages were developed 40 years ago, this was perceived as too much syntax.

> nice and clear

Looks absolutely horrible to me, why not simply

    eax = ebx + ecx

?

I guess because there's no simple infix operator for every operation implemented by the machine. Also, the addition may be floating-point or 32, 16, or 8 bit, signed or unsigned, possibly vectorized. An opcode is a good place to express these things.

Opcodes are fine, no one is saying everything has to be expressed as an operator. I'd like to see more of a C/C++ intrinsics syntax, but with total control over the order of instructions and register allocation. Basically same power as assembly, syntax close to intrinsics, but you tell it which registers to use, and there's one instruction per line, and they're executed exactly as you write them, with no creativity on the part of the compiler.

+1. Make it look more like a severely restricted version of C.

The best set of arguments I've seen against it: http://x86asm.net/articles/what-i-dislike-about-gas/

All the intel docs use intel syntax, and for some instructions converting between the 2 syntax forms isn't immediately obvious.

I wish there was a version of Intel's docs with AT&T syntax.

Wow. Literally a 40 year old thread!

well not quite, but slightly more than 30 years - you point is right - those who don't read history are doomed to repeat it

I thought gas did both...

It does, now, but it used to not.

Reply on news.ycombinator.com