I feel it's primarily x86-64 assembly that's so ridiculously hard to read, not least owing to the dozens of extensions and two syntaxes (GNU/AT&T versus Intel syntax). Furthermore, it is a register-memory ISA, and has a flags register which is set as instructions are executed, both of which lead to a lot of implicit behaviour that isn't immediately obvious from reading a given listing of x86-64 assembly.
In contrast, the entire MIPS32 specification fits on one sheet of paper[1], and MIPS was used in some very productive and entertaining applications—the Sony PS1, PS2, and PSP, for instance.
ARM is similar, as is RISC-V (although the former has a flag register). I find these RISC assemblies in general more straightforward than x86-64. They are also register-register, load-store architectures that make memory accesses quite explicit.
This doesn't mean x86-64 or CISCs in general are inferior or superior to RISCs. They are two different approaches to the same problem, and as AMD has shown, it is possible to achieve good efficiency on CPUs using CISC ISAs, too.
I feel it's mostly the problem of the first impression. My first encounter with assembly was x86 and so it didn't really bother me ("ah, so that's what it is, okay"), and other assemblies were felt to be basically the same, maybe marginally nicer, maybe marginally worse, but that's it. But I do imagine that if your first foray into assembly started with RISC-V, then looking at x86 would absolutely scare you.
Then again, 6502 specs can probably fit on one sheet of paper too, just as MIPS32 did, and it too has been used in very productive and entertaining applications—and yet it's even more idiosyncratic than x86; I've seen considerably more examples of "an instruction that sets flags; anywhere from 1 to 10 instructions that don't set flags; conditional branch" pattern in 6502 code than in x86.
I guess it's similar to learning functional vs. imperative programming language as your first intro to programming?
P.S. AT&T syntax for x86 is
a) backwards: "subl %eax, %ebx" vs "sub ebx, eax" for "ebx -= eax", ugh;
b) pretends that numbers are weird functions: "subl -32(%ebx,%ecx,4), %eax" vs "sub eax, [ebx+ecx * 4-32]" for "eax -= MEMORY_AS_ARRAY_OF_INT32[ebx+ecx * 4-32]", what the hell, minus thirty two is most definitely not a function with three arguments; neither is it a three dimensional array if we pretend that parens stand for array indexing as they do in FORTRAN.
> I feel it's mostly the problem of the first impression.
That's fair. I started out with MIPS32. When I first saw x86 instructions, and a `mov`, my first thought was, 'what the heck? Where are the loads and stores? `mov rax, [rip + 32]` is 3 instructions in MIPS or any similar RISC, this looks weird.'
> P.S. AT&T syntax for x86 is
Oh, yeah, I hate it. x86 instructions can already get pretty long; now you have multiple suffixes just to account for size. The indexing operation is just ridiculous; Intel syntax makes it so much more straightforward.
6502 has too many ways to address the memory (incl all the zero page), it will require quite a few pages not a single one. Indeed the lda/ldx/ldx change the flags unlikely 8086's mov.
I learned 6502 assembly as a kid right after basic... and ever since always had enjoyed it. Pretty much until the compilers became better optimizing code than me (not the 6502 one, of course)
In contrast, the entire MIPS32 specification fits on one sheet of paper[1], and MIPS was used in some very productive and entertaining applications—the Sony PS1, PS2, and PSP, for instance.
ARM is similar, as is RISC-V (although the former has a flag register). I find these RISC assemblies in general more straightforward than x86-64. They are also register-register, load-store architectures that make memory accesses quite explicit.
This doesn't mean x86-64 or CISCs in general are inferior or superior to RISCs. They are two different approaches to the same problem, and as AMD has shown, it is possible to achieve good efficiency on CPUs using CISC ISAs, too.
[1]: https://inst.eecs.berkeley.edu/~cs61c/resources/MIPS_Green_S...