Hacker News Reader

Comment by mmrezaie | Hacker News Reader

Why did they choose to not have RVC? Also, what happens if one of these groups working on RISC-V decides they need to add a couple of more instructions in there? Is there a group that you can send your patches for the review like Linux kernel? I do not understand the compatibility of the risc-v cpus!

View on HN

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 spec calls out code density as the reason.

> 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.

In a sibling comment "neuron_clash" states that when work on shakti started RVC was considered an optional extension, and by the time the community decided RVC should be mandatory it was too late for shakti to support it.

Reply on news.ycombinator.com