Claire Xen  🏳️‍⚧️ 🏳️‍🌈 🧙🏻‍♀️ BLM  🏴 🚩

I used to have a formally verified correct RISC-V core. With the release of v2.3 it will be out of spec. What happened to no backwards incompatible changes after v2.0? What happened to spike is the executable golden reference? It's all lies..

Rocket of course used to be out of spec up to and including v2.2 of the spec. Starting with v2.3 rocket will magically be in spec and every other implementation that did it correct before will suddenly be in violation of the spec. Nothing matters.

Just a side issue: I believe you have “no incompatible changes” backwards. The goal is for old software to work on new CPUs, not for old CPUs to run new software. Reserved opcodes are always intended to be able to be used in later specs, not illegal forever.

What you mean is for new extensions. E.g. RV32I code should run on an RV32IM machine. But within an extension backward compatibility goes both ways. If I make a RV32I core now it should be able to execute RV32I code generated by a compiler 10 years from now.

I don’t think that’s true. v3 RV32I can include opcodes not present in v2 RV32I. You’ll need to tell your future compiler to restrict itself to v2 opcodes.

A jump from v2 to v3 may do that. That's because RV32I2 and RV32I3 are different ISAs, thus have different ISA subset names. But 2.2 and 2.3 are both RV32I2 and they may only differ in resolving ambiguities and holes. That is the promise given by the foundation to implementers.

Maybe, though I haven’t seen that written anywhere.