"For the 10 years it's been heralded as the saviour of open computing it's still very marginal, sadly."
That's what exponential growth looks like -- not worthy of notice for a long time, and then suddenly it's everywhere.
Look at the number of hospitals recently saying "we'll worry about coronavirus when we see a case" and then one or two weeks later they're "Our ICU is filled to overflowing and we're having to decide who we just let die, we're running out of beds with oxygen, 10% of our doctors have caught it and the rest are working 18 hour days and aren't allowed to see their families".
If you haven't noticed:
- Samsung has said the new Galaxy S20 has one RISC-V core controlling the camera and another controlling the 5G radio.
- Qualcomm has said every SoC they ship from now will have RISC-V in it somewhere.
- Espressif have said the new version of the ubiquitous ESP32 wifi/Bluetooth chip with main CPU core still Xtensa but an ultra low power RISC-V management core has gone to volume production.
- Microchip / MicroSemi has said the version of their avionics / military-qualified FPGA with embedded penta-core RISC-V FU540 is available to qualified customers for development now, available in volume Q3.
- Western Digital / Sandisk should be shipping their first disks and flash drives with RISC-V in them later this year.
It takes companies like these four or five years to go from "Hey, that looks interesting" to volume production. All those companies started working on RISC-V products years ago -- and it wasn't really available to people outside Berkeley until 2015 -- and you can be sure many many others have started the process in the last couple of years.
As for extensibility. The vast majority of custom instructions I've seen proposed don't affect the rest of the software in the system, don't even require changing compilers. These instructions are usually used in two or three places in a software library to speed up some specialized thing by a factor of five or twenty or whatever. Often it's not even worth modifying the assembler to know about them -- it woudl be easier overall to just encode them in hex with a .word directive where you need them.
But in fact the RISC-V GNU assembler has a special ".insn" directive that lets the user's program source define a new instruction using any of a number of standard instruction encoding formats and then immediately use it -- no modifications to the assembler.
For details see https://embarc.org/man-pages/as/RISC_002dV_002dFormats.html
That covers small, secret, extensions anyone can make.
Larger RISC-V extensions that will be standardized and made available for everyone go through a review process where experts from *many* companies and universities and research organisations look at them, try experimental implementations of them, suggest improvements etc. This process slows things down, but it's quite likely that the end result will be of *better* quality than any one company would do.