4 ms·
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
by amluto 2y ago
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.
- jcranmer 2y agoDon't forget the weirdness of AVX-512 masks in AT&T syntax!
- amluto 2y agoI 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.
- ack_complete 2y agoAT&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.
- m463 2y agoI 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.
- clausecker 2y agoARM 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.
- rep_lodsb 2y agoSorry, 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 :)
- musicale 2y agoJP (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.
- m463 2y agoI 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.