Hacker News Reader

Comment by amluto | Hacker News Reader

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 book. The correct order for the operands of ADD is what the corresponding manual says.

2. Intel address syntax is so much better than AT&T’s that it’s not even funny.

View on HN

Don't forget the weirdness of AVX-512 masks in AT&T syntax!

I sincerely hope I never have to touch code like that.

I have messed with code to save and restore AVX-512 registers, and this is about the only thing I like about AT&T syntax: there’s a uniform way to specify the instruction size that works when the instruction has no operands. I’m looking at you, XSAVE, XRSTOR, SYSRET, etc. The manual has no useful syntax to offer here.

AT&T syntax for x86-64 introduces tons of nonstandard instruction names that you will never find in the official manuals. WTF are: movabs, cqto, filds, and ljmp?

I also don't understand why x86 syntax has to be mutilated when special syntax is supported for other architectures. It's somehow OK for ARM64 to have [x1, w9, sxtw #2] or [x3, #32]! and 68K to have (%a2,%d1.l8), but x86-64 can't have [%rcx + %rdx4].

Reading x86-64 disassembly in AT&T syntax is just painful.

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.

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

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.

I remember the Z80 in relation to the 8080. I might have misremembered but I thought Z80 allowed some combinations that 8080 could not do. It could also be that the assembler/syntax itself was nicer.

Reply on news.ycombinator.com