Well, it's explicitly designed so that vendors can add custom extensions. But code that sticks to standard instructions (anything that pure C/C++ code can compi

Well, it's explicitly designed so that vendors can add custom extensions. But code that sticks to standard instructions (anything that pure C/C++ code can compile to, basically) should be 100% compatible. There are conformance tests in the process of being created, but that's not fully in place yet. But with so few instructions, which are all used by software of any significant size, if you successfully boot Linux then it can't be far off :-) More extensions are in the process of being ratified before the end of the year. The big one is the Vector extension, which allows code using vectors/SIMD to execute completely unchanged on machines with vector registers anywhere from 128 bits to 64k bytes in size. I know of one apparent implementation compatibility bug that's just been diagnosed. GeekBench, for whatever reason, is using the fairly new FENCE.TSO instruction in their code. A bit pointless as I don't think they are yet any RISC-V cores that implement TSO memory semantics, so a FENCE RW,RW would do just as well. The FENCE opcodes have a largish field with the lower bits giving pred and succ R, W, I, O bits. In the base FENCE instructions the upper bits are all zero. Future FENCE instructions are supposed to be designed so that if a CPU ignores the upper bits then they devolve to some slightly stronger standard fence. So FENCE.TSO for example is FENCE RW,RW with one of the upper bits set. It seems that the Alibaba C906 core (in the Allwinner D1 chip on the Nezha board) is not treating unknown upper bits in FENCE as if they are all zeros as the spec says, but is instead giving an illegal instruction trap. Fortunately, this can be worked around by adding a FENCE.TSO emulation handler (or FENCE with upper bits set in general) to OpenSBI, alongside the emulation of things such as misaligned loads and stores. These can be safely present in the M mode software for every CPU type as they will never be triggered if the hardware handles those things directly. Of course the trap and emulate performance penalty will be far far greater than any minor performance improvement from using FENCE.TSO instead of FENCE RW,RW on a (hypothetical at this point) machine that actually implements the TSO extension.