[rep_lodsb]

>For example, why "mov eax, [ebx + 2 * ecx + 4]" is allowed, but not "mov eax, [ebx + ecx + edx]"

Because it's translated into a single machine instruction!!! "mov eax,[[ebx]]" doesn't work either - not on x86 at least, historically there were architectures that had indirect memory references :)

It's still MUCH easier to read and write. How do you even remember the order in AT&T syntax? Shouldn't the scale factor maybe be given as a shift count since that's how the hardware works? By using familiar arithmetic expressions, it becomes perfectly clear what is meant, and anyone who actually writes assembly will quickly learn what forms are allowed. And if you are only reading the code, it doesn't matter.

Of course, AT&T syntax comes from UNIX, where the zeroth commandment is "Thou shalt have no other programming languages but C and shell scripts". People who have invested the effort to memorize something like 42 different levels of operator precedence, and fluently read and write symbol vomit like "(((void *)(int [])fn(foo,bar=baz==quux++))" are obviously desperate to make assembly look EVEN MORE complicated...

[spcharc]

> Because it's translated into a single machine instruction!!!

Actually we never learned the x86 binary representation of instructions in that assembly language class. The textbook also did not cover that.

All I wanted to say is: Intel syntax hides the fact that there are only 4 things in address calculation: displacement, base, index, scale. The compilation error is also hard to understand (at least for the compiler I used). It says something like "the expression is invalid" but you never know what went wrong.

AT&T syntax exposed the underlying requirement, and the compilation error is easy to understand.

Now I am okay with both AT&T and Intel, but when I was learning, I appreciated AT&T syntax more. Assembly is mandatory for CS major in that college, and AT&T syntax made my semester easier.

[rep_lodsb]

It's easy enough to learn "base + index*scale +- displacement". And it can be written in exactly that way, in whatever order makes the meaning of the code clearest, as you would do it in a higher level language.

AT&T syntax forces you to learn this before writing or even reading a single line of code that references memory, instead of giving the illusion that maybe something like [eax+ebx+ecx] or [[eax]] was also allowed. I don't think that's very helpful. It also forces you to learn a very specific way of writing it that is completely unintuitive.

I'm somewhat sympathetic to the argument that assembly syntax should correspond to the underlying hardware, just not to such an extreme. For example, I prefer 8080 over Z80 for that reason (one mnemonic for each addressing mode).

[spcharc]

> It's easy enough to learn "base + index*scale +- displacement".

Well, you already know this requirement, so it is not a problem for you. However for learners, who don't have even the remotest idea of machine instructions, all they get is some invalid expression error messages. Same message for all (1) (2) and (3) cases I listed above.

Maybe Intel syntax works better for experienced programmers. But at least for me, when I was a newbie to assembly, AT&T was better than Intel syntax. It made learning process easier.

> AT&T syntax forces you to learn this before writing or even reading a single line of code that references memory

I do believe that rules forced by language is a good thing. At least it helped me understand why (1) (2) and (3) didn't work

Many people believe Rust can help people write safer code. Why? Because of its rules. Incorrect ownership will be discovered by the borrow checker so a compilation error will force the programmer to correct it.

Maybe an experienced C++ programmer will be able to handle memory management correctly in C++, and loves the extra freedom that C++ brings. But Rust can be helpful for learners. It provides clear error message helping them understand why their code is wrong. While in C++? Segmentation fault.

(Needless to say, Rust also helps experienced programmers. Even experienced programmers write buggy C++ code.)