Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

outerproduct.net

Post reply on HN
Print view View original

81–90 of 112 posts

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

#81

Post by kazinator »

im3w1l wrote: post #46
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!

Well consider consistency. In assembly's case. Using to from order makes it consistent with C. Consistent with manuals. And in the case of arithmetic instructions, consistent with the order used in mathematical notation. On the other hand for shell scripts, using from to makes it more consistent. With what? Pipelines read a from-file process it and then write. from to.

Ironically, to from order makes it consistent with memcpy/memmove. But that ISO C function came from AT&T Unix. BSD has bcopy which uses "AT&T syntax".

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

#83

Post by torstenvl »

gergo_barany wrote: post #78
torstenvl wrote: post #73

Earlier quoted context omitted.

No, Intel gets the distinction exactly right: "The MOV instruction performs basic load data and store data operations between memory and the processor’s registers and data movement operations between registers." https://cdrdv2-public.intel.com/819723/325462-sdm-vol-1-2abc... Volume 1, page 7-3 (page 181 of the PDF). In the context of assembly, load/store refers to memory ⇆ register.

https://www.felixcloutier.com/x86/lea : "LEA — Load Effective Address" https://www.felixcloutier.com/x86/mov-2 : "MOV — Move to/from Debug Registers ... At the opcode level, the reg field within the ModR/M byte specifies which of the debug registers is loaded or read. The two bits in the mod field are ignored. The r/m field specifies the general-purpose register loaded or read."

Completely irrelevant to the conversation.

The question is whether "Intel also uses 'load' in the descriptions of register-to-register moves."

What Felix Cloutier says is not probative on this question.

What Intel says in Intel's manual posted on Intel's website is the definitive authority on what Intel says on the matter.

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

#84

Post by rep_lodsb »

NikkiA wrote: post #56
IshKebab wrote: post #29

Earlier quoted context omitted.

I think because it's always in the same place and always first. That definitely emphasises it. Personally I think assembly should just have a little more syntax. If we wrote dst = mv src or dst it would just be obvious.

The operand order is because intel were flip flopping between load semantics and move semantics with the 4004, 8008, 8080, 8085, 8086 progression. Remember that when the 8080 engineers left to found Zilog, they changed the MVI instruction to LD, as it had been intended. (LD on 4004 and 8008, MOV on 8080, LD/ST and MOV on 8085, MOV on 8086)

8080 and 8085 are basically the same, and have both MOV, MVI and LD/ST. The advantage is that the mnemonics directly correspond to the operations supported by the hardware, once you learn them you know what registers can be used where.

Z80 is also highly unorthogonal (even more so than x86), but obscures this by using the same mnemonic with different operand combinations, not all of which are legal and some require prefix bytes.

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

#85

Post by trealira »

OnionBlender wrote: post #64

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.

I haven't played Exapunks, so I can't say, but about AT&T vs Intel: maybe the order of "mov source, destination" and "sub subtrahend, minuend" is easier, since it lines up with English phrases like "move this into that" and "subtract this number from that number," but everything else about Intel syntax was easier for me when I first learned assembly.

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

#86

Post by spcharc »

rep_lodsb wrote: post #76
spcharc wrote: post #69

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…

>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 may…

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

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

#87

Post by trealira »

pclmulqdq wrote: post #10

As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. * The suffixes give you a lot of easy specifi…

> As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it.

Wow, that surprises me. Without knowing anything, I would think it were the other way around, because in Intel syntax, the address calculation is more explicit than the comma-and-parentheses form; the registers don't require a % sign every time, making it distracting to read the code; and the opcodes are easier to read out loud because they lack the suffixes.

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

#88

Post by rep_lodsb »

spcharc wrote: post #86
rep_lodsb wrote: post #76

Earlier quoted context omitted.

>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 may…

> 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…

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

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

#89

Post by gergo_barany »

torstenvl wrote: post #83
gergo_barany wrote: post #78

Earlier quoted context omitted.

https://www.felixcloutier.com/x86/lea : "LEA — Load Effective Address" https://www.felixcloutier.com/x86/mov-2 : "MOV — Move to/from Debug Registers ... At the opcode level, the reg field within the ModR/M byte specifies which of the debug registers is loaded or read. The two bits in the mod field are ignored. The r/m field specifies the general-purpose register loaded or read."

Completely irrelevant to the conversation. The question is whether "Intel also uses 'load' in the descriptions of register-to-register moves." What Felix Cloutier says is not probative on this question. What Intel says in Intel's manual posted on Intel's website is the definitive authority on what Intel says on the matter.

https://cdrdv2-public.intel.com/819723/325462-sdm-vol-1-2abc..., Vol. 2A page 3-598 (physical page 1191): "LEA—Load Effective Address"

https://cdrdv2-public.intel.com/819723/325462-sdm-vol-1-2abc..., Vol. 2B page 4-42, (physical page 1263): "MOV—Move to/from Debug Registers ... At the opcode level, the reg field within the ModR/M byte specifies which of the debug registers is loaded or read. The two bits in the mod field are ignored. The r/m field specifies the general-purpose register loaded or read."

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

#90

Post by rep_lodsb »

trealira wrote: post #87
pclmulqdq wrote: post #10

As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. * The suffixes give you a lot of easy specifi…

> As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. Wow, that surprises me. Without knowing any…

I suspect it's just a different culture. People coming from UNIX and C learn from tutorials that use AT&T syntax, and probably would never think of writing code in assembly to begin with.
Post reply on HN