>>5AArch64 gives you a few more bits, but it's like they took the worst of RISC and CISC when they designed it. Not all types of loads and stores work with all addressing modes, you can use a shift count for some instructions in some operands but not others, sometimes register 31 is the stack pointer and sometimes it's the always-zero, they finally made unaligned accesses work the way they should --- except that the stack pointer might want to be 16-aligned (remember this is an arch with almost all 8-byte registers) for no fucking reason depending on what the OS prefers but most of those idiots were too retarded to turn that feature off, sometimes certain combinations of bits of the opcode are "undefined" also for no fucking reason, the width of immediate values can be 5, 6, 7, 9, 13, or 21 bits depending on which exact variant of instruction, there's
over three dozen different "load" instructions... all of which is written somewhere in the almost 8000 pages of documentation, that doesn't even provide an opcode map. That's not counting the specific SoC datasheet either, which is another several thousand pages. Who said RISC was supposed to be simpler...? MIPS is simple, but slow and bloated. I guess AArch64 is what happens when you try to turn a RISC into a CISC just so it can remain competitive with x86. Nothing else can explain the insanity of the irregular addressing modes and instructions that try to fit more than one operation into those 4 bytes.
At least with x86 you just have a ModRM and possibly SIB, and that's it with addressing modes that apply to nearly all instructions with very few combinations like lea reg, reg being undefined, the second page of opcodes is a little hairy but the first page is consistently patterned, and immediate values are sanely sized and all their bytes/bits contiguous.
>>7They are documented now. If you don't implement them, you can't call it 100% x86-compatible.