> On the contrary: the compiler and programmers have performance expectations. Just as modern compilers/programmers expect macro-op fusion between x86 cmp/jmp p

> On the contrary: the compiler and programmers have performance expectations. Just as modern compilers/programmers expect macro-op fusion between x86 cmp/jmp pairs, modern ARM compilers/programmers expect fusion between AESE and AESMC. I understand that compilers and programmers have expectations. I just don't see how that determines the CISC-ness of an ISA specification. (Again: see my RISC-V example.) That said, it's a bit of a side argument. > Does that make AMD Zen's implementation of AMD64 a RISC machine? No, it does not. The fact that you have different pipelines for different parts of the ISA enables maintaining a RISC-like architecture. That doesn't mean that it is RISC. For me, the complexity of the decoder is the determining factor. > ARM kind of has this instruction set called "Thumb2" you probably should get familiar with. Which by the way, all ARM8 chips still support if you put them into AArch32 bit mode. I thought Thumb2 instructions can either be 16-bit or 32-bit wide, like RISC-V compressed instructions. x86 allows a free mix of 8 bit, 16 bit, 24 bit, 32 bit and 40 bits. As a hardware designer, the former is minor decoder implementation nuisance. The latter is a nightmare. I was not aware that THUMB2 allowed byte-aligned instructions of variable length. > EDIT: Its really, really difficult for me to consider ARM a real RISC machine. I'm sorry. It supports all of the PDP-11 addressing modes for goodness sake. (post-decrement, pre-increment, etc. etc.). Nothing is ever black and white. If somebody considers mixing 16-bit and 32-bit instructions CISC, then CISC it is. My bar is just at a different level. > Or is "LDR R0, [R1, r2, LSL #2]" really a RISC-style instruction? Why would it not be?