Does anyone know how well RISC-V will be able to compete with ARM in the higher end? It seems pretty easy to come up with a processor design that is competitive in low-compute load applications, but what about more advanced designs? I'm curious what it is that ARM brings to the table there and if there is a chance that RISC-V will ever offer serious competition.
Certainly RISC-V does not need to be the best to survive as a viable option for most designs. It may absorb a lot of market share from ARM in the long run. It will be interesting to see how it develops.
That's actually the wrong way round.
For advanced designs the instruction set really doesn't matter that much, the bulk of the silicon in a modern advanced CPU is spent doing things like caching, branch prediction, instruction scheduling, buffering loads and stores that may be unwound due to speculation, address translation, etc. These things are completely instruction set agnostic. To see how little it matters look how well x86 processors work despite the x86 instruction set being a mess (even figuring out how long an instruction is in bytes is a nightmare) or how well advanced ARMv7 processors despite that instruction set being a mess (a free shift on every immediate, urgh).
Now low-power is a completely different game. The bulk of the CPU is spent doing really quite basic stuff, fetching instructions, decoding instructions, simple ALU ops. Tiny differences to the instruction set can make a big difference to how much silicon (thus power) this takes. This is why RISC-V offers a 'reduced' variant (with only 16 registers), they know that for any low-power design the vast majority of silicon area is just going to be spent on flip-flops or latches for the 32 entry register file (what a waste given the tiny performance bump in moving from 16 to 32 registers). That's a lot of leakage power for no reason.
Now RISC-V is not necessarily a great instruction set, but it's not really an awful instruction set either (from a pure perspective of implementing an efficient 32-bit CPU, I'm sure it has academic advantages). For example nobody implements a RISC-V CPU without the 'C' extension (16-bit instructions) and given that they really should have just made all instructions 16-bit with optional 16-bit or 32-bit payloads (typically immediates). This would have meant it was only a single instruction to load a 32-bit constant rather than two and code density would be higher (thus less power spent fetching and decoding instructions). On the other hand you'd have a lot less extensibility available. Probably this would require 16 registers instead of 32 (not enough bits in the 16-bit instructions otherwise), but again this is a good thing for lower power in small CPUs.
So RISC-V will never be the best instruction set for low-power 32-bit CPUs, but it's definitely better than x86 and ARMv7, and that's probably enough. And for 'advanced' designs it just doesn't matter, it's all about the quality of the implementation.
Personally I dislike RISC-V but I will still use it for implementing CPUs (and already have) due to the toolchain support. Designing your own instruction set is fun but porting a compiler is not, and RISC-V is sufficiently 'not bad' that it does the job. I imagine a lot of people feel similarly.
Yeah, I like RISC-V generally, especially the base and the vector extension. However, they really went off the rails with the Bit Manipulation Extensions [1] still in draft form. Compare bfp which mixes control + data in the same register with ARMv8 bfi. It's only been added since the 0.92 draft but it seems to me very un-RISC-like.