I've always viewed x86 as the worst of both worlds. It lacks the orthogonality of a good CISC, and it lacks the simpleness of a RISC. That modern x86 chips perform so well is despite their inefficient ISA, not because of it. If as much money and research got poured into anything else, it'd perform even better.

I can't believe I'm defending x86 but I think you're being too harsh. Orthogonality isn't really that important these days now that everybody uses compilers and the very messiness of x86 has allowed Intel to keep adding new instructions over time.

Linus waxes poetic on 'rep movs' but I'd rather have something like PAL code for architecture specific optimized routines for implementing copies. Still, that's something most ISAs don't have.

All production ARM hardware retains the old ISA. The 64 bit transition made it more CISCy, not less. Don't confuse an instruction architecture with a CPU.

Yes, essentially all ARM chips are going to support the old ISA. I'm not sure I understand your criticism though? RISC and CISC are terms that always apply to an ISA rather than a CPU, I hope I didn't accidentally imply anything else.

It's important because when people have silly internet wars over this stuff, they end up picking one side or the other because of its effect on actual hardware.

So to say that AArch64 made things simpler is just wrong: all actual 64 bit ARM CPUs in fact implement a more complicated ISA using more die area and more power than their 32 bit predecessors.

In some sense it's more complicated because it's implementing more instruction sets but that's not as big a deal as you might think. ARMs have been doing that for a while, besides the normal A32 ISA there's also Thumb, Jazelle, etc. But while adding ISAs does take some die area it doesn't take too much since ARM instructions are very easy to decode. And that extra die area doesn't cost any power since when you're using A64 you can turn off the A32 decoder.

Now you're doing exactly the same things that Intel people do when ARM folks claim that x86 is hard to decode. :)

Look, by any objective measure, a shipping AArch64 CPU is "more CISCy" than an ARMv7 one. Claiming that it is not because some particular subset of its functionality (that can never be shipped in isolation) is clean is a kind of cognitive dissonance.

I mean, if you want to flame about "architecture subsets", the 8086 was a pretty "clean" architecture too. The datasheet with full instruction set and all addressing modes fit on like 3 pages.

The 8086 instruction set was small but it wasn't a RISC instruction set by any means. It only had a few registers and those it had were tied to fixed semantics. It had microcoded instructions. And many of its instructions involved both memory access and arithmatic. Those features were fine in the 70s but in the 80s they were problematic as people started to use pipelining and things like that.

The when you talk about RISC or CISC you're talking about styles of ISA design influenced by the technical constraints of the eras they arose in. ARM's 64 bit design shares a great many elements with the classic RISC design: 32 registers, 32 bit instructions, load-store, no prediction, etc. It's much more similar to the original RISC processor than ARM's 32 bit design was. If I were designing it I would have gone for for 16 registers and a self synchronizing variable length instruction format arranged around 16-bit chunks more like Thumb. But I'm just some dude who did his thesis on computer architecture then hared off and worked on sensors systems - I don't have any real practical experience so I'm not going to claim that I know better than ARM's engineers.

You can certainly claim that ARMv8 is more complex than ARMv7. But I can't see how you can argue that ARMv8 is less RISC like than ARMv7.

I give up, because you clearly don't see my point. Your using a narrow, essentially academic definition for "[CR]ISC" to justify a real-world sounding argument with terms like "die area" and "power" and "decode". That's insane, sorry.

Last time, then I'm gone: "AArch64 is a simpler RISC ISA architecture" is true, and "AArch64 CPUs have simpler decode units" is false, yet you seem to be arguing the former as evidence for the latter.

I'm afraid I'm still not sure exactly what we're disagreeing about or if we even have a disagreement. If you mean that CPUs that implement AArch64 and AArch32 are going to require more silicon and design effort devoted to their decoders than ARVv7-A CPUs of course I'd agree. If you mean that these CPUs will spend more power decoding when using A64 then I'm not sure but I'd tend to doubt it. If you mean that AArch64 CPUs have more complicated decode units than x86 CPUs than I would confidently disagree (modulo decode width and to a lesser extent clock speed).

If you're saying that the distinction between RISC and CISC isn't very important then I would agree with you, at least for high end processors. Ever since the Pentium Pro people have known how to avoid paying the price for complicated instructions outside of the decode unit and there are CISC instruction sets (not x86) that are relatively easy to decode.

Its not the ISA. Its always been about what simplifying the ISA got you: longer pipelines, simpler register-collision resolution, bigger caches on-chip. That's where the speed came from.

Now that entire complex ISAs can be implemented in a fraction of the real estate of an L0 cache, it matters less. And super-scalar, hyperthreading etc have taken the baton from pipelining.

Right. Ever since the late 90s ISA lost most of its importance on the high end. The most important factor for ISAs these days is probably code density since instruction cache pressure can be an important factor in some workloads.

Ease of decode still matters a bit. IIRC Bulldozer used 5-10% of its power budget on decode and Intel finds it worthwhile to have a cache of decoded instructions. But that's still a relatively small factor in the grand scheme of things.