Live data from Hacker News

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

outerproduct.net

71–80 of 112 posts

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

#71

Earlier quoted context omitted.

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.

MASM was also excessively wordy in many other areas. The amount you had to write to introduce a new segment or access something from another segment was ridiculous. I guess they probably improved that in later releases after TASM showed you didn't need any of that nonsense (and just had .TEXT and .DATA instead).

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

#72
post #34

Earlier quoted context omitted.

> It also sort of lines up with C and C++ syntax of putting the result on the left. The article also discussed this argument, and I find it weird, because higher level languages also put the operation on the right side. Maybe I just prefer having the operation and the target close together? Having `abs(x) = y` put the absolute value of y into x, would be extremly weird to me in C++. > I might be biased as an Intel-sy…

Careful, in C++ `abs(x) = y` is equally likely to put y into abs(x). Jokes about C++ aside, many DSPs with their own assembly languages have chosen to learn from C and higher level languages. The following style of syntax is not uncommon for DSPs (I am not using a specific one, but an abstract style), where writing assembly is expected: R1 = R2 + R3; R5 = R1 * R3; R4 = POPCOUNT(R1); R3 = [R0] Curiously, RISC-V didn't…

> Careful, in C++ `abs(x) = y` is equally likely to put y into abs(x).

I know, if it returned something it could write into, it would. .__. https://godbolt.org/z/7h6YMqbEW

> Jokes about C++ aside, many DSPs with their own assembly languages have chosen to learn from C and higher level languages. The following style of syntax is not uncommon for DSPs (I am not using a specific one, but an abstract style), where writing assembly is expected:

> R1 = R2 + R3 R5 = R1 * R3 R4 = POPCOUNT(R1) R3 = [R0] That's really cool to know, my exposure to assembly is mostly limited to a little bit disassembly for all kinds of reasons (so mostly x86 reading) or 1 instance of inline assembly. Most of the other instances I worked with SSE intrinsics instead, so my knowledge is very limited.

This thread was extremly interesting to read.

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

#73

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

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.

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

#74

Earlier quoted context omitted.

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.

Which assembler requires that? Let me guess, GAS in Intel mode, just to make it more painful because they don't want you to use it?

NASM syntax:

    mov   rax,[Foo]             ;load var into reg, QWORD is implicit
    add   dword [Bar],1234h     ;add constant to DWORD var
    movzx eax,byte [rsi]        ;zero extend BYTE to DWORD reg

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

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

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

#77
>For example, consider the following number >030514 >...that number is understand to mean ‘add the contents of registers A1 and A4, and store the result in register A5’. The association between this numeric form and its meaning under the ISA is completely arbitrary

They are not as arbritary as first glance as they might appear, related functions often cluster together creating families of opcodes. How many instructions in the family, what circuits and hardware components they use, and other optimization factors influence the arrangement of instructions as well which can determine the binary number the opcode uses.

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

#78

Earlier quoted context omitted.

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.

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

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

#79

> ...you should still clean your CPU at least annually: use soap, warm water, and a soft rag to get the gunk out of the transistors. I know the author is just making a joke here, and it is funny. Somehow it reminded me of some actual advice I've seen more than once on /r/thinkpad. I am paraphrasing from memory, but I'm sure I have the gist of it: > When you get a brand new ThinkPad in a factory sealed box, the first…

Reminds me of a little quip in a 68000 programming language book I read a long time ago. Paraphrasing: "Upon executing HALT, the processor will stop, and nothing short of a reset will get it going again. Although threatening it with a hammer has been known to work on occasion, especially if it knows you've killed before."

And there will always be a customer that writes to support asking what size hammer should be used to test that parameter.

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

#80

Earlier quoted context omitted.

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.

Which assembler requires that? Let me guess, GAS in Intel mode, just to make it more painful because they don't want you to use it? NASM syntax: mov rax,[Foo] ;load var into reg, QWORD is implicit add dword [Bar],1234h ;add constant to DWORD var movzx eax,byte [rsi] ;zero extend BYTE to DWORD reg

NASM is good, but yes, GAS in Intel mode wants you to be very wordy. I believe MASM is the most annoying one for Intel syntax, though.
Post reply on HN