Live data from Hacker News

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

outerproduct.net

101–110 of 112 posts

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

#101
post #94
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…

I learned ibm 370 assembly first, PDP-11 assembly second, then I think Z80. I found them to be very regular and understandable. So when I encountered intel chips and their assembly syntax, I disliked them. So about that time I switched to higher level languages. Are there still chips left have a nice orthogonal assembly language? I vaguely recall 68k being orthogonal too.

ARM is pretty orthogonal, though arm64 is less so. RISC-V is very orthogonal, but it sucks to program for it in assembly as the instruction set is missing even basic features.

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

#102
post #94
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…

I learned ibm 370 assembly first, PDP-11 assembly second, then I think Z80. I found them to be very regular and understandable. So when I encountered intel chips and their assembly syntax, I disliked them. So about that time I switched to higher level languages. Are there still chips left have a nice orthogonal assembly language? I vaguely recall 68k being orthogonal too.

Sorry, but Z80 being "regular and understandable"?

    ADD  A,B     ;8 bit add, B to A
    ADD  HL,BC   ;16 bit add, BC to HL
    ADD  B,A     ;invalid! destination can only be A or HL

    ADC  A,B     ;add with carry
    SBC  A,B     ;subtract with carry
    SUB  B       ;subtract (A is implicit, same for AND,OR,XOR)

    LD   A,(HL)  ;load A from memory at HL
    LD   B,(HL)  ;load B from HL
    LD   A,(DE)  ;load A from DE
    LD   B,(DE)  ;invalid! must be reg=A or mem=(HL)

    LD   A,(var)  ;load A from variable
    LD   HL,(var) ;load HL from variable
    LD   DE,(var) ;extra opcode byte, 4 cycles slower
    LD   B,(var)  ;invalid! must be A or register pair

    JP   (HL)     ;load PC with contents of HL register, NOT MEMORY!

    EX   DE,HL   ;exchange DE with HL (no other registers allowed)
    EX   HL,(SP) ;exchange HL with top of stack (no other reg,mem allowed)
    EX   AF,AF'  ;wtf were they thinking?
    EXX          ;should be EX BCDEHL,BCDEHL' for consistency :)

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

#103
post #98

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…

How many of them have experience with other assembly languages? For me, it was exposure to M68k that made Intel syntax seem absolutely awful. AT&T syntax is also awful, but at least the operand order is the way that I'm (still) more used to.

Many of the assembly writers have exposure across platforms, but often with modern assemblers whose syntax tracks Intel syntax more closely.

I don't know why 68000 is so popular here (maybe people on HN learned it in school?), but you're far more likely to be writing ARM assembly or these days RISC-V assembly than writing for an antiquated core like the 68000.

Believe it or not, outside the x86 world, Intel-style syntax has basically won.

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

#104
post #53

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

> [src, dst] is closer to human language In English, but not Telugu.

Programming languages are pretty much always in English though, including these mnemonics.

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

#105
post #41

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

IMO there shouldn't be a way to run programs without named arguments.

Have you ever programmed in objectivec or swift? I imagine what you're describing working something like that, but on the command line.

A few years back, mpv changed to make named arguments require an equals rather than a whitespace. I've gotten used to it, but it seems like such a weird outlier.

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

#106
post #98

Earlier quoted context omitted.

How many of them have experience with other assembly languages? For me, it was exposure to M68k that made Intel syntax seem absolutely awful. AT&T syntax is also awful, but at least the operand order is the way that I'm (still) more used to.

Many of the assembly writers have exposure across platforms, but often with modern assemblers whose syntax tracks Intel syntax more closely. I don't know why 68000 is so popular here (maybe people on HN learned it in school?), but you're far more likely to be writing ARM assembly or these days RISC-V assembly than writing for an antiquated core like the 68000. Believe it or not, outside the x86 world, Intel-style syn…

Because assembler used to be common, and isn't anymore, and because M68k assembler was nice to write, and because the Amiga and Atari were big once.

I abandoned assembler when I switched to Linux and got my first PC because x86 assembler was so awful I couldn't bear working with it.

AT&T syntax made it slightly less atrocious through familiarity, but only slightly.

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

#107
post #6

Fun little thing: If you really want to confuse an LLM, try to make it reason about x86 assembler, and watch it trip all over operand order (along with many other things). I've had models assume different operand order in two different places in the same file. x86 assembler really is the gift that keeps on giving. Sadly it doesn't given you anything nice.

Honestly they don't do much better for Z80 or 6502 assembly from what I've seen either.

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

#108
post #67

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;

tests the raku...

  my $b = 42;
  my $c = False; 

  $b ^^ $c ==> my $a; 
  say $a;    #[42]
^^ yep

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

#109

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

Reading the Wikipedia page on Halt and Catch Fire it seems this issue actually caused a certain set of illegal opcodes to become an "official' HCF instruction (opcode was DD so it was also known as "Drop Dead") as it was also later used by the engineers for product testing or something.

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

#110
post #94

Earlier quoted context omitted.

I learned ibm 370 assembly first, PDP-11 assembly second, then I think Z80. I found them to be very regular and understandable. So when I encountered intel chips and their assembly syntax, I disliked them. So about that time I switched to higher level languages. Are there still chips left have a nice orthogonal assembly language? I vaguely recall 68k being orthogonal too.

Sorry, but Z80 being "regular and understandable"? ADD A,B ;8 bit add, B to A ADD HL,BC ;16 bit add, BC to HL ADD B,A ;invalid! destination can only be A or HL ADC A,B ;add with carry SBC A,B ;subtract with carry SUB B ;subtract (A is implicit, same for AND,OR,XOR) LD A,(HL) ;load A from memory at HL LD B,(HL) ;load B from HL LD A,(DE) ;load A from DE LD B,(DE) ;invalid! must be reg=A or mem=(HL) LD A,(var) ;load A f…

JP (HL) seems to be a disambiguator vs. JP HL (jump to label HL) and the register swap instructions, while quirky, seem justifiable as well.

I would just add SUB A, B (etc.) and call it a day.

edit: looks like the Z800 was an improved/orthogonalized (and pipelined!) extension of the Z80 that maintained software compatibility. And it looks like the SUB A, B format is supported by eZ80 assemblers, though A is still the only valid 8-bit accumulator.

Post reply on HN