3 ms·
It's "reserved" which is basically the same as C's UB - anything can happen (nasal dragons etc.) so you can't rely on it.
by IshKebab 2y ago
It's "reserved" which is basically the same as C's UB - anything can happen (nasal dragons etc.) so you can't rely on it.
- bigstrat2003 2y agoJust because it's reserved doesn't mean anything can happen. On x86_64, you get a clearly defined error when you use reserved bits and the like. I don't know if RISC-V is the same, but if it isn't it's because they chose to be vague, not because that's what it means to be reserved.
- dzaima 2y agoFor what it's worth, the RISC-V unprivileged spec says: > The behavior upon decoding a reserved instruction is UNSPECIFIED. > Some platforms may require that opcodes reserved for standard use raise an illegal-instruction exception. Other platforms may permit reserved opcode space be used for non-conforming extensions. The RVA23 says: (https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...) > Implementations are strongly recommended to raise illegal-instruction exceptions when attempting to execute unimplemented opcodes or access unimplemented CSRs. and has an optional extension "Ssstrict": > Ssstrict No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to the supervisor-mode trap handler.
- fulafel 2y agoI guess being unpriviliged this still guarantees the dragons are restricted your process, otherwise the chip would have a security problem. So as a heuristic you could fork your process, and try to execute SIMD operations (detecting known nonstandard versions and failing them), and if results seems fine send a "ok" flag up a pipe. (or compile this into a separate test executable)