I was discussing this with someone involved with the project and it comes down to wanting to handle only 32 bit instructions (RVC instructions are 16 bit; other RISC-V extensions can have > 32 bit instructions, although of course if you don't support any of those extensions then you don't have to deal with it). This is a simplifying assumption in the decoder element in their pipeline.
RISC-V does allow you to define other extensions in a methodical and detectable way, and we intend to detect those at runtime (as you would, for example, with something like AES-NI or AVX on Intel). However RVC impacts every bit of compiled code so there's no way to deal with it at runtime (something like that would make all binaries much bigger and would greatly complicate the toolchain).
i like it how they just want to process 1 length instructions (32bit). that's so much easier to build for debuggers/assemblers etc. i think it's a good move to allow for people to write custom OS onto it. As the more complicated aspects of generating machine code have gone, it's easier to write targeted compilers, assemblers and debuggers etc. i find this very interesting choice!
It's probably more about the hardware's instruction decoder. The RVC code has unaligned 32-bit instructions, and that greatly increases the complexity at instruction decode time. Now you have to worry about crazy stuff like an instruction that straddles two different pages.
I'm surprised to hear this, I would have expected a 16bit noop being necessary to align 32 bit instructions..
Is-there a summary of the discussion about this choice?
> The standard compressed ISA extension described in Chapter 14 reduces code size by providing compressed 16-bit instructions and relaxes the alignment constraints to allow all instructions (16 bit and 32 bit) to be aligned on any 16-bit boundary to improve code density.
The only solution I see is to launch a JIT translator (cough QEMU cough) whenever an illegal instruction exception pops, and hope for the best. Certainly not the best choice not to support RVC when everybody else does.
RISC-V does allow you to define other extensions in a methodical and detectable way, and we intend to detect those at runtime (as you would, for example, with something like AES-NI or AVX on Intel). However RVC impacts every bit of compiled code so there's no way to deal with it at runtime (something like that would make all binaries much bigger and would greatly complicate the toolchain).