Nowadays it just doesn't matter, because CPUs translate ISA into whatever they please.
Cache and out of order buffers (speculation) is what is behind latest security issues.
That's one way to look at it. Another is that opaque CPU designs are a big issue (at least for meltdown, which is a bug; spectre is more of a broken design philosophy).
Doing that comes at a cost, which compounds the complexity already added by merit of being CISC in the first place.
Besides, this translation layer is not a major source of complexity anymore. Even instruction decoding in x86 is not a big deal anymore.
What larger code size?
RISC-V is no worse than x86-64.
Refer to: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu...
Being a new ISA, RISC-V does have an advantage of being able to learn from past mistakes.
It's very nice, indeed. Unlike the established RISC ISAs, this one's created with decades of RISC (and CISC) experience to draw from.
I'd of course still have my doubts whether this is going to draw any traction, if it wasn't for the list of RISC-V Foundation members.
RISC only made sense when logic cycle times, memory cycle times, and I/O cycle times were at rough parity.
As for your claims on RISC not making sense, I'll just say it makes more sense than ever, as complexity leads to issues, which could affect security, and security is important in the present networked world.
This is why Spectre is as ubiquitous as it is. Speculative execution is not a feature someone implements just for the sake of it.
Requires is debatable. If someone manages to match it with a simpler design, it's an improvement. RISC-V open implementations are surprisingly very competitive already.
>With a very simple ISA,
Seems to imply that this is a minus, but what CISC really means in the present world is that there's a CISC->RISC translation layer, which is not free, and a lot of work passed down to toolchain developers, as they have to generate code for a CISC ISA.
In x86/amd64, the complexity is such that no individual can be expected to understand the whole thing, and CPU designers, low level software and compiler developers have to deal with this (and will inevitably screw up). Why this isn't seen as a massive problem baffles me.
More like a mixture of something like CISC->VLIW and CISC->"micro-ops". Remember x86 implementations can actually combine x86 ISA instruction pairs into a micro-op [0].
RISC is just a concept that was a great fit to the constraints the industry had in the nineties. It was great for achieving high clock speeds back then. The constraints are just different nowadays.
In RISC-V parlance, it'd be the new vector extensions. They're pretty cool as they've made the width variable. Refer to 7th workshop proceedings.
>micro-ops
Are a fancy word. It just means a (hidden) RISC architecture. There's a bunch of RISC architectures out there, but they get down to doing more or less the same things.
Most RISC and CISC architectures in use today are evolved from ones existing back in the 80s, and carry a lot of baggage. RISC-V benefits from having a clean slate at this, using the experience of existing ISAs.
>can actually combine x86 ISA instruction pairs into a micro-op
More complexity, and more tickets for the implementation bug lottery.
> More complexity, and more tickets for the implementation bug lottery.
Well, the slides (and accompanying paper) you linked to earlier in this thread makes the cases for using macro-op fusion in high-performance RISC-V designs.
Very nice and very clean when done as they propose with this RISC ISA.
The more the complexity, the harder it is to keep software (or hardware, which for CPUs is defined as software) bug-free.
CISC simply has no place in the networked world, and RISC-V is the best RISC architecture.