4 ms·

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

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.

ajross 11y ago
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.
- Symmetry 11y ago
  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.

ajross 11y ago

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.

Symmetry 11y ago
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.