Is it an option on RISC-V to transparently emulate opcodes on cores that implement only a subset of an extension? This extension in particular seems to be a good candidate.
The usual way to support a larger instruction set than is actually implemented in the chip is to "trap" unimplemented instructions, and then emulate them with a subroutine in the runtime library. A trap is like an interrupt, but generated from the instruction stream.
Of course this is a lot slower than the instruction might have been, but at least the code runs and produces the right answer.
Sometimes the trap does not change the execution sequence of externally visible instructions, but instead directs the machine to execute a sequence of internal microcode, while externally it looks like the machine has stalled. Indeed, on some machines all instructions trap this way.
Modern CISC chips do a more sophisticated form of the latter, where RISCs have typically avoided it for most or all operations.
So, whether and how RISC-V implementations emulate extensions will vary. Emulation generally doesn't produce very nice results, for this kind of operation -- the purpose of the instruction is to give users access to custom machinery wired into the core, for speed, and without the machinery the programmer might have preferred to achieve the results some other way.
RISC-V is only an instruction set architecture, not a microarchitecture. It describes how things work from a software point of view, but it does not require any specific implementation, and it does not require anything to be fast. You can implement instructions with microcode or software if you want to.
No, your original assumption is correct. It is explicitly stated (though I can't remember where) that it is acceptable for a compliant RISC-V core to trap and emulate instructions that it doesn't natively support.
